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(54) Point-to-point protocol encapsulation in ethernet frame 



(57) A wireless data network which provides com- 
munications with a Pier to Pier Protocol server is dis- 
closed. The network includes a home network that in- 
cludes a home mobile switching center, a wireless mo- 
dem and one or more end system. The wireless modem 



and the end systems are connected together via an eth- 
ernet link. The network also includes a PPP server, 
wherein PPP information sent from PPP server for the 
end systems is encapsulated by the wireless rnodem in 
an ethernet frame and sent to the end systems via the 
ethernet link. 
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Description 

Background of the Invpntinn 
^ Field of the Invention 

Description Of R^i^t^^ 

S 'o'^Jer'cfmTufels "thlthTseTr^^^ working together typica.ly provide remote ir^ternet 

[0003] The first business entity I ,he tetepSne companv S^^^^^ ""^'""^ ^ '^^"^'''"'^ ^V^^-'^S- 

Phone system (POTS) or integrated se^ices data n^raSn^woTrrf ''^ "'^'""P ^'^^ 

S^o,J™o;^^^^^^^ 

.ablishes a POP in each major local calling are' wS fhe ,SP exoLTT' '"k" ^" '^'^ '^P^'V es- 
message traffic from the PSTN run by the teli im^a ^ ^,1 '° ^"''^'^"''^ customers. The POP converts 

.he ISP or leased from an intranet backbond Sii"ik?S r An rs^:"' T ^° ''V 

fractional or full T3 lines from the telco for connectrt^to pSn thTp^^^^ °^ ^1 lines or 

are connectedtogether over the intranet backbone rough roureM2A ?L H ?' ^"'^ '^^^'"'^ "^'^ 

ma,l seniors, accounting and registration servers onSo mTiSP t h '""'^^ '""^ '^^'^ ^^l' ^^'vers, 

sendees to end users. Future value added services r^L ^e add-d L 

center. The ISP also maintains router 12A to rnrec7?o^utJc1nter Lt'b"^^^^^^^ '"o""""' ""^'^ ^^"^^ '^^ 
access, end users have service relationships with theJ Scf and h J ^S' T ^° -^^^^l ^«"^ote 

End users access the ISP. and through the TsP pub Jc nt^ net 20 Lv Hilf T "^P^^^'^ "'"^ '^"^ t'o'h. 

n^t^n protocol known as the Internet Engineering Ta^k Fori ^PTpf^^ ' ^"""'"9 ^ 

[0005] The third business entity is the orivatP ^nl?!^ . Force (IETF) po.nf-to-point protocol (PPP). 
router 1 2B for business reason^ CoZZ l^ZeTr.T'' ""^ P--'« intranet 1 8 through 

on the road) by making POTS.SDN ^^To coXT^'^roraSsT^^^^ <^ ^ ' - ^^^^ 

For corporate access, end users only pay for the cost ot^TZr^nZ ^""^ '"""'"^ '''^ '^TF PPP Protocol. 

pin're.^2^%rs:.— 

psers^r;;; tSp ;:~ r^pTn^t^kTndi^r °' ^ - - - 
rro'^^x--!^m^^^^^^^^ 

hosting services and roaming to Ld use^Beca^^^^^^^^^ 

on features and price. ISPs are looking Jor vaTue L^i^^^^^^^ 

vendors will be able to offer solutions to ISPs to enabt^hertroVe^ ZT"^ ""^'^'"^ ^^^^^^^^ 
-s the abilrty to use public networks securely as pri^t J ni^or^T^'^T' P^'"^'^ networking (which 

push technologies and quality of serv,ce. in iUe lZTxerTZ^.ZV^ r"'" '° consort.ums. 
will use these value added services to escar,<r,° m!l . ' ® ^""^ "mobility will also be offered ISPs 

fail in the category of network servi anTcTn ro^e^eSlTv^'" ZT'''' ''^"^ °' '"^^^ ^'^ added seS 
rail in the category o, applica.ion services which req^^^^^^^^ T'T '"'^^'-^-^ -q^'P--' Others 

require any support from the network infrastructure Se4L Tike Z 'n'r^sTuclure. while others do not 

mobility, voice, quality of service, quality of sei^ice b-..T. '""^'^"'^^ Pr^^ate networking, roaming 

system described here will be either direct p ov d^'nesl enh'a^nc 'd se "^'"^^^ infrastructure. Th'e 

can be added later as future enhancements vJ^|l„ ^"^^a^^ed services or provide hooks so that these sen/ices 



Summar y Of The Inv^nti^r. 
[0008] 
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in foreign networks with interchange agreennents. 

[CX)09] It is an object of the present systenn to provide a wireless packet switched data network for end users that 
divides nnobiltty management into local, micro, macro and global connection handover categories and minimizes hand- 
off updates according to the handover category. It is another object to integrate MAC handoff messages with network 

5 handoff messages. It is a further object of the present system to separately direct registration functions to a registration 
server and direct routing functions to inter-working function units. It is yet another object to provide an intermediate 
XTunnel channel between a wir(?l(9.ss hub {8!so CB!!6d bcc*?S9 hub AH) and sn Ipt^r-v/orkipc^ function unit (!WF unit) in 
a foreign network. It is yet another object to provide an IXTunnel channel between an inter-working function unit in a 
foreign network and an inter-working function unit in a home network. It is yet another object to enhance the layer two 

10 tunneling protocol (L2TP) to support a mobile end system. It is yet another object to perform network layer registration 
before the start of a PPP communication session. 

[0010] According to one embodiment of the invention, a wireless data network which provides communications with 
a Pier to Pier Protocol server is disclosed. The network includes a home network that includes a home mobile switching 
center, a wireless modem and one or more end system. The wireless modem and the end systems are connected 
^5 together via an ethernet link. The network also includes a PPP server, wherein PPP information sent from PPP server 
for the end systems is encapsulated by the wireless modem in an ethernet frame and sent to the end systems via the 
ethernet link. 

Brief Description Of Drawings 

20 

[0011] The system will be described in detail in the following description of preferred embodiments with reference to 
the following figures wherein: 

FIG. 1 is a configuration diagram of a known remote access architecture through a public switched telephone 
25 network; 

FIG. 2 is a configuration diagram of a remote access architecture through a wireless packet switched data network 
according to the present invention; 

50 FIG. 3 is a configuration diagram of selected parts of the architecture of the network of FIG. 2 showing a roaming 

scenario; 

FIG. 4 is a configuration diagram of a base station with local access points; 

35 FIG. 5 is a configuration diagram of a base station with remote access points; 

FIG. 6 is a configuration diagram of a base station with remote access points, some of which are connected using 
a wireless trunk connection; 

"^0 FIG. 7 is a diagram of a protocol stack for a local access point; 

FIG. 8 is a diagram of a protocol stack for a remote access point with a wireless trunk; 

FIG. 9 is a diagram of a protocol stack for a relay function in the base station for supporting remote access points 
-^5 with wireless trunks: 

FIG. 10 is a diagram of protocol stacks for implementing the relay function depicted in FIG. 9: 

FIG. 11 is a diagram of protocol stacks for a relay function in the base station for supporting local access points: 

50 

FIG. 1 2 is a configuration diagram of selected parts of the architecture of the network of FIG. 2 showing a first end 
system registering in the home network from the home network and a second system registering in the home 
network from a foreign network using a home intcr-working function for an anchor: 

55 FIG. 1 3 is a configuration diagram of selected parts of the architecture of the network of FIG. 2 showing a first end 

system registering in the home network from the home network and a second system registering in the home 
network from a foreign network using a serving inter-working function for an anchor: 
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*^ a configuration diagram of protocol stacks showing communications between an end system in a home 
t~ fe^s ~ ir "^'^^^^ ^"^^ acclsTSrcoSp^: 

n^wf rVL'dThorelTis?!^^ protocol stacks showing communications between an end system in a foreign 
network and a home registration sender in a home network during the registration phase; 

s^?tem^ " ^ "'"^^'""^ ^'^^^^^ P^-^^^^'^S °' ^'^'^^-'ina data through to the customer billing 

in ;?ore^"n^:o^: '^^ST' ^" ^"'^ ^^"^"^ ^ ^'^^^ 

nS^f ftfr"" ^^^^^ d'^S^^'"^ depicting an end system connection in a home network where a PPP 

pl?p^nrol^o?,f ^ are protocol Stack diagrams depicting an end system connection in a foreign network where a 

zsTinTrrtn::;^^^^^^^^^ 

TnSn e!hLtrframT '° ^ "'"'^^^ - encapsulated 

FIG. 30 illustrates an ethernet frame format; 
FIG. 31 illustrates XWD Header fields: 

mina.es at"me ^^e^s r^er ' '''' " ^ ^'^^^'^ ^^^^ 

h^doffscrn:S,fesp:cS;- '^'''^'"^ ^ ^'^^-^^^ ^ — *° - -aero 

^^JJ^:^^;^::^:::;^ ^ ^^-^^^ ^^^-^^ -^-^ "^^^-^ '^^ '--S- -^istratlon sen.er and the 
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Detailed Description Of Preferred Embodiments 

[001 2] The present system provides computer users with remote access to the intemet and to private intranets using 
virtual private network services over a high speed, packet switched, wireless data link. These users are able to access 
the public internet, private intranets and their inter net service providers over a wireless link The network supports 
roaming, that is, the ability to access the internet and private intranets using virtual private network services from 
anyvvhera that ti^e services o"ereu by tiie piesenl syslein ciie tivaiiable. Trie network atso suppoas handoffs. thai is, 
the ability to change the point of attachment of the user to the network without disturbing the PPP link between the 
PPP client and the PPP server. The network targets users running horizontal internet and intranet applications. These 
applications include electronic mail, file transfer, browser based WWW access and other business applications built 
around the internet. Because the network will be based on the IETF standards, it is possible to run streaming media 
protocols like RTP and conferencing protocols like H.323 over it. 

[0013] Other internet remote access technologies that are already deployed or are in various stages of deployment 
include: wire line dial-up access based on POTS and ISDN, XDSL access, wireless circuit switched access based on 
GSM/CDMA/TDM A, wireless packet switched access based on GSM/CDMA/TDMA, cable modems, and satellite 
based systems. However, the present system offers a low cost of deployment, ease of maintenance, a broad feature 
set, scaleabtlity. an ability to degrade gracefully under heavy load conditions and support for enhanced network services 
like virtual private networking, roaming, mobility and quality of service to the relative benefit of users and service pro- 
viders. 

[0014] For wireless service providers who own personal communications system (PCS) spectrum, the present sys- 
tem will enable them to offer wireless packet switched data access services that can compete with sen^^ices provided 
by the traditional wire line telcos who own and operate the PSTN. Wireless service providers may also decide to become 
Intemet service providers themselves, in which case, they will own and operate the whole network and provide end to 
end services to users. 

[001 5] For inter net service providers the present system will allow them to by-pass the telcos (provided they purchase 
or lease the spectrum) and offer direct end to end services to users, perhaps saving access charges to the telcos. 
which may increase in the future as the intemet grows to become even bigger than it is now. 

[0016] The present systems flexible so that it can benefit wireless service providers who are not internet service 
providers and who just provide ISR internet or private intranet access to end users. The system can also benefit service 
providers who provide wireless access and internet services to end users. The system can also benefit service providers 
who provide wireless access and Internet services but also allow the wireless portion of the network to be used for 
access to other ISPs or to private intranets, 

[0017] In FIG. 2, end systems 32 (e.g., based on, for example. Win 95 personal computer) connect to wireless 
network 30 using external or internal modems. These modems allow end systems to send and receive medium access 
control (MAC) frames over air link 34. External modems attach to the PC via a wired or wireless link. External modems 
are fixed, and, for example, co-located with roof top mounted directional antennae. External modems may be connected 
to the user's PC using any one of following means: 802.3, universal serial bus. parallel port, infra-red, or even an ISM 
radio link. Internal modems are preferably PCMCIA cards for laptops and are plugged into the laptop's backplane. 
Using a small omni-directional antenna, they send and receive MAC frames over the air link. End systems can also 
be laptops with a directional antenna, a fixed wireless station in a home with a directional antenna connected via AC 
lines, and other alternatives. 

[0018] Wide-area wireless coverage is provided by base stations 36. The base station 36 can employ a 5-channel 
reuse communication scheme as described in U.S. Patent Application Serial No. 08/993.505. filed on December 26, 
1 997. The range of coverage provided by base stations 36 depends on factors like link budget, capacity and coverage. 
Base stations are typically installed in cell sites by PCS (personal communication services) wireless service providers. 
Base stations multiplex end system traffic from their coverage area to the system's mobile switching center (MSC) 40 
over wire line or microwave backhaul network 38. 

[0019] The syslem is independent ol the MAC and PHY (physical) layer of the air link and the type of modem. The 
architecture is also independent of the physical layer and topology of backhaul network 38. The only requirements for 
the backhaul network are that it must be capable of routing internet protocol (IP) packets between base stations and 
the MSC with adequate performance. At Mobile Switching Center 40 (MSC 40), packet data inter-working function 
(I WF) 52 terminates the wireless protocols for this network. IP router 42 connects MSC 40 to public internet 44, private 
intranets 46 or to internet service providers 46. Accounting and directory servers 48 in MSC 40 store accounting data 
and directory information. Element management server 50 manages the equipment which includes the base stations, 
the IWFs and accounting/directory servers. 

[0020] The accounting server will collect accounting data on behalf of users and send the data to the service provider's 
billing system. The interface supported by the accounting server will send accounting information in American Man- 
agement Association (AMA) billing record format, or any other suitable billing format, over a TCP/IP (transpon control 
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protocol/inter net protocol) transport to the billing system (which is not shown in the figure). 

[0021] The network infrastructure provides PPP (point-to-point protocol) service to end systems The network pro- 
vides (1 ) fixed wireless access with roaming (log-in anywhere that the wireless coverage is available) to end systems 
and (2) low speed mobility and hand-offs. When an end system logs on to a network, in it may request either fixed 
service (i e stationary and not requiring handoff services) or mobile service (i.e., needing handoff services). An end 
system that does not specify fixed or mobile is regarded as specifying mobile service. The actual registration o the 
end system is the result of a negotiation with a home registration server based on requested level of service, the level 
oi services subscribed lo by the user of the end system and the facilities available in the network. 
[0022] If the end system negotiates a fixed service registration (I.e., not requiring handoff services) and the end 
system is located in the home network, an IWF (inter-working function) is implemented in the base station to relay 
traffic between the end user and a communications server such as a PPP server (i.e., the point with which to be 
connected, for example, an ISP PPP server or a corporate intranet PPP server or a PPP sen/er operated by the wireless 
service provider to provide customers with direct access to the public internet). It is anticipated that perhaps 80 /o of 
the message traffic will be of this category, and thus, this architecture distributes IWF processing into the base stations 
and avoids message traffic congestion in a central mobile switching center. 

r00231 If the end system requests mobile service (from a home network or a foreign network) or if the end system 
request roaming sen/ice (i.e., service from the home network through a foreign network), two IWFs are established: a 
serving IWF typically established in the base station of the network to which the end system is attached (be it the home 
network or a foreign network) and a home IWF typically established in mobile switching center MSG of the home 
network Since this silualion is anticipated lo involve only about 20% of the message traffic, the message traffic con- 
qestion around the mobile switching center is minimized. The serving IWF and the wireless hub may be co-located in 
the same nest of computers or may even be programmed in the same computer so that a tunnel using an XTunnel 
protocol need not be established between the wireless hub and the serving IWF 

[0024] However, based on available facilities and the type and quality of service requested, a serving IWF in a foreign 
network may alternatively be chosen from facilities in the foreign MSG. Generally the home IWF becomes an anchor 
point that is not changed during the communications session, while the serving IWF may change if the end system 

moves sufficiently. ,, . . ... „ 

[0025] The base station includes an access hub and at least one access point (be it remote or collocated with the 
access hub) Typically, the access hub serves multiple access points. While the end system may be attached to an 
access point by a wire or cable according to the teachings of this invention, in a preferred embodiment the end system 
is attached to the access point by a wireless 'air link", in which case the access hub is conveniently referred to as a 
wireless hub While the access hub is referred to as a "wireless hub" throughout the description herein, it will be ap- 
preciated that an end system coupled through an access point to an access hub by wire or cable is an equivalent 
implementation and is contemplated by the term "access hub". 

[0026] In the invention, an end system includes an end user registration agent (e.g.. software running on a computer 
of the end system, its modem or both) that communicates with an access point, and through the access point o a 
wireless hub The wireless hub includes a proxy registration agent (e.g.. software running on a processor in the wireless 
hub) acting as a proxy for the end user registration agent. Similar concepts used in. for example, the IETF proposed 
ly/lobile IP standard are commonly referred to as a foreign agent (FA). For this reason, the proxy registration agent of 
the present system will be referred to as a foreign agent, and aspects of the foreign agent of the present system that 
differ from the foreign agent of tvlobile IP are as described throughout this description. 

[0027] Using the proxy registration agent (i.e., foreign agent FA) in a base station, the user registration agent of an 
end system is able to discover a point of attachment to the network and register with a registration server in the MSG 
(mobile switching center) of the home network. The home registration sender determines the availability of each of the 
plural inter-working function modules (IWFs) in the network (actually software modules that run on processors in both 
the MSG and the wireless hubs) and assigns IWF(s) to the registered end system For each registered end systerri. a 
tunnel (using the XTunnelproXoco\) Is created between the wireless hub in the base station and an inter-working function 
(IWF) in the mobile swilching center (I^SG), this tunnel Iransporling PPP frames between ihe end syslem and ihe IWF 
[00281 As used herein, the XTunnel protocol is a protocol that provides in-sequence transport of PPP data frariies 
wrth flow control. This protocol may run over standard IP networks or over point-to-point networks or over switched 
networks like ATM data networks or frame relay data networks. Such networks may be based on T1 or T3 links or 
based on radio links, whether land based or space based. The XTunnel protocol may be built by adapting algorithms 
from L2TP (level 2 transport protocol). In networks based on links where lost data packets may be encountered, a re- 
transmission feature may be a desirable option. 

[0029] The end system's PPP peer (I.e., a communications server) may reside in the IWF or in a corporate in anel 
or ISP-s network When the PPP peer resides in the IWF, an end system is provided with direct internet access. When 
the PPP peer resides in an intranet or ISP an end system is provided with intranet access or access to an ISP In order 
to support intranet or ISP access, the IWF uses the layer two tunneling protocol (L2TP) to connect to the intranet or 
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ISP's PPP server. From the point of view of the intranet or ISP's PPP server, the I WF looks like a network access server 
(NAS). PPP traffic between the end system and the IWF is relayed by the foreign agent in the base station. 
[0030] In the reverse (up link) direction. PPP frames traveling from the end system to the IWF are sent over the MAC 
and air link to the base station. The base station relays these frames to the IWF in the MSG using the XTunne/ protocol. 
5 The IWF delivers them to a PPP server for processing. For internet access, the PPP server nnay be in the same machine 
as the IWF. For ISP or intranet access, the PPP server is in a private network and the IWF uses the layer two tunneling 

\JiK^\.\^\^i^\ * < / ^V./t II ICOi li. 

[0031] In the forward (down link) direction, PPP frames from the PPP server are relayed by the IWF to the base 
station using the XTunne/ protocol. The base station de-tunnels down link frames and relays them over the air link to 

^0 the end system, where they are processed by the end system's PPP layer 

[0032] To support mobility, support for hand-offs are included. The MAC layer assists the mobility management soft- 
ware in the base station and the end system to perform hand-ofts efficiently. Hand-offs are handled transparently from 
the peer PPP entities and the L2TP tunnel. If an end system moves from one base station to another, a new XTunnel 
is created between the new base station and the original IWF The old XTunnelUom the old base station will be deleted. 

75 PPP frames will transparently traverse the new path. 

[0033] The network supports roaming (i.e., when the end user connects to its home wireless service provider through 
a foreign wireless service provider). Using this feature, end systems are able to roam away from the home network to 
a foreign network and still get service, provided of course that the foreign wireless service provider and the end system's 
home wireless service provider have a service agreement. 

20 [0034] In FIG. 3, roaming end system 60 has traveled to a location at which foreign wireless service provider 62 
provides coverage. However, roaming end system 60 has a subscriber relationship with home wireless service provider 
70. In the present invention, home wireless service provider 70 has a contractual relationship with foreign wireless 
service provider 62 to provide access services. Therefore, roaming end system 60 connects to base station 64 of 
foreign wireless service provider 62 over the air link. Then, data is relayed from roaming end system 60 through base 

2S station 64, through serving IWF 66 of foreign wireless service provider 62, to homo IWF 72 of home wireless service 
provider 70, or possibly through home IWF 72 of home wireless service provider 70 to internet service provider 74. 
[0035] An inter-service provider interface, called the I -interface, is used for communications across wireless service 
provider (WSP) boundaries to support roaming. This interface is used for authenticating, registering and for transporting 
the end system's PPP frames between the foreign WSP and the home WSP 

30 [0036] PPP frames in the up link and the down link directions travel through the end system's home wireless service 
provider (WSP). Alternatively. PPP frames directly transit from the foreign WSP to the destination network. The base 
station in the foreign WSP is the end system's point of attachment in the foreign network. This base station sends (and 
receives) PPP frames to (and from) a serving IWF in the foreign WSP's mobile switching center. The serving IWF 
connects over the l-interface to the home IWF using a layer two tunnel to transport the end system's PPP frames in 

35 both directions. The serving IWF in the foreign WSP collects accounting data for auditing. The home IWF in the home 
WSP collects accounting data for billing. 

[0037] The serving IWF in the foreign WSP may be combined with the base station in the same system, thus elim- 
inating the need for the X-Tunnel. 

[0038] During the registration phase, a registration server in the foreign WSP determines the identity of the roaming 
40 end system's home network. Using this information, the foreign registration server communicates with the home reg- 
istration server to authenticate and register the end system. These registration messages flow over the l-interface. * 
Once the end system has been authenticated and registered, a layer two tunnel is created between the base station 
and the serving IWF using the XTUNNEL protocol and another layer two tunnel is created between the serving IWF 
and the home IWF over the l-interface. The home IWF connects to the end system's PPP peer as before, using L2TP 
-^5 (level 2 tunnel protocol). During hand-offs. the location of the home IWF and the L2TP tunnel remains fixed. As the 
end system moves from one base station to another base station, a new tunnel is created between the new base 
station and the serving IWF and the old tunnel between the old base station and the serving IWF is deleted, if the end 
system moves far enough, so lhal a new serving IWF is needed, a new tunnel will be created between Ihe new serving 
IWF and the home IWF. The old tunnel between the old serving and the home will be deleted. 
so [0039] To supports roaming, the l-interface supports authentication, registration and data transport services across 
wireless service provider boundaries. Authentication and registration services are supported using the IETF Radius 
protocol. Data transport services to transfer PPP frames over a layer two tunnel are supported using the l-XTunnel 
protocol. This protocol is based on the IETF L2TP protocol. 

[0040] As used in this description, the term home IWF refers to the IWF in the end system's home network The term 
55 serving IWF refers to the IWF in the foreign network which is temporanly providing service to the end system. Similarly, 
the term home registration server refers to the registration server in the end system's home network and the term 
foreign registration server refers to the registration server in the foreign network through which the end system registers 
while it is roaming. 
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^^7^^ ^'""^"^ ^^"^'"'^ 'P ^'^d^^ss assignment for end systems There are two tVDes 

bl rrtrir H '° -nsidered. The first is the identity of the end system in its home ne work Zs^l 

be a structured user name .n the format user@domain. This is different from the home IP address used in mobitelP 
The second address .s the IP address assigned to the end system via the PPP IPCP address negofiatfon process T^^^ 

?hTurersubTll '° ^^^^"^ ^ '"'^ qualiSZSin name 

the end i H .1 k . "^^"^ '° "'^"'''^ '''^ ""^^ ^^'"^ ^he User-Name is stored on 

^"."J^^'l? ^""^ ♦'^^ ^"bscnber data-base at the MSG and is assigned to the user when he or she subscribes to 
U.O oo. voo^ oomaH. suo-,.e,d of the User-Name is used during roaming lo identify roaming relationshins and the 
home reg.strat,on server for purposes of registration and authentication. Instead of the structu^eJuler name another 
unique ident.f.er may be used to identify the user's home network and the user's identity in the homrne^ofk Thi 
Identifier is sent in the registration request by the end system network. This 

f^TpnH JJ'Jl^^ Z?^, '° '""^ ^""^'^^^ ^^'""3 'P configuration protocol IPCP 

the end system IS able to negotiate a fixed or dynamic! P address an or 

[0043] Although the use of the structured user-name field and the non-use of an IP address as the home address is 

en? v'^ms t?at h^^^^^^^ ' ""''"^ "^'^^^ enhanceSralso support 

PPP end sTilr^I J user-name and only a non-null home address, if mobile IP and its use in conjunctton with 
durfno m<f IprP HH ' "^'^ ''''^ "^"^^^ "^^y ''^ configured by the service provider to assign IP addresses 

during the IPCP address assignment phase that are the same as the end system's home IP address In this case the 
home address and the IPCP assigned IP address will be identical 

Elr InH IS.?;"^"^ ^'^!'?" ^""^ """^ ^""^ ^y^'^"'^ ^'^^'^^^ sub-network 80 that includes the air 
^g S uI^Z L T; "^^^ <^ 9 • t'^-'^haul network (e.g.. 38 of 

FIG. 2) from the base station to MSC 40 (FIG.2). The wireless sub-network architecture of. for example a 3-sectored 
base station includes the following logical functions. example, a j sectored 

Ir,i.t^!f^rf '^"''^^ ®^ P*"^""^ "^^^ ^AC layer association and dissociation 

cir^uf A^1r\^ TIT ^ processor (preferably in the form of custom application specific integrated 

c. cuit ASIC), a link to a wireless hub (preferably In the form of an Ethernet link on a card or buHt into the ASIC) 
JTZ^^ f ? <Pf ^/^bly In the form of a card with a data modulator/demodulator and a transmitter/receiver) 

funct^n^^^dl"! ! ^'^'^"^ """P'"'' ■'^^ ^""^ *° P^rfo^-^ ^ data bridging 

functHDn and vanous other functions in support of registration and mobility handovers as further described herein 
See discussion with respect to FIGS. 7, 8 and 11 . 

Th. MA?i!r'"'^ ^'^^^l '^"^ ''^""^^ ''""^ ^"^ ^^'^y ^^^-^ '° « «'*reless hub and vice versa 

The MAC layer assocation and disassociation procedures are used by APs to maintain a list of end system MAC 

To^MAC aS^essf '"^"'^ "'m?'" ^" '^^^^ ''"^^^^ on beha^ of end sXs 

r^^fonT^ ^"^."^Tf, ^'^^^"^ ^^"'^ ^ ^'^'^^^^ P°'"' associated wireless hub are typically co- 

located. In Its simplest form, an access point is just a port into a wireless hub. When the APs and the wireless hub 
are co-located in the same cell site, they may be connected together via a IEEE 802.3 link Sometimes access 
points are located remotely from the wireless hub and connected via a long distance link like a wired Tt'tmnk or 
even a wireless trunk. For multi-sector cells, multiple access points (i.e , one per sector) are used. 

fe TtZ^r!:u^Z"TV^. 84 performs the foreign agent (FA) procedures, backhaul load balancing 

t^:.l7c^^y ^' r^^^'^' ""^^^^'^ 'nterfacing, and the x/i/nne/ procedures. When support for quality of 
ba^h^. S^^H '".r^T^: """^'^^^ '"'^ implements the support for QOS by running the xtunnel protS=ol over 
bTruUiprarceTsTo^tf ' ^ ^'"^'^ "'^^'^^^ 'Vp'cally shared 

.inw ^7J'^'^H^ ^"k ^ processor, a link to one or more access points (preferably in the form of an Ethernet 

link on a card or built into an ASIC), and a link to a backhaul line. The backhaul line is typically a Tl or T3 com- 
munications line that terminates in the mobile switching center of the wireless service provider The link to the 
backhaul line formats data into a preferred format, for example, an Ethemet format, a frame relay format or an 
ATM format. The wireless hub processor runs software to support data bridging and various other functions as 
aescribed herein. See discussion with respect to FIGS. 9, 10 and 11. 

t0045] The base station design supports the following types of cell architectures. 

1. Local AP architecture In a local AP architecture, access points have a large (> = 2km, typically) range They 
are co-located '" the cell site with the wireless hub (FIG. 4). Access points may be connected to the wireless hub 
using an IEEE 802.3 network or may be directly plugged into the wireless hub's backplane or connected to the 
wireless hub using some other mechanism (e g universal serial bus, printer port, infra-red. etc ) It will be assumed 
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that the first alternative is used for the rest of this discussion. The cell site may be omni or sectored by adding 
nnultiple access points and sectored antennas to a wireless hub. 

2. Remote AP architecture. In a remote AP architecture access points usually have a very small range, typically 
around 1 km radius They are located remotely (either indoors or outdoors) from the wireless hub. A T1 or a wireless 
trunk preferably links remote access points to the cell site where the wireless hub is located. From the celt site, a 
wire iine backhaui or a microwave link is xypicaiiy used lo connect to me iwF in the MSG. If wireless trunking 
between the remote AP and the wireless hub is used, omni or sectored wireless radios for trunking are utilized. 
The devices for trunking to remote access points are preferably co-located with the wireless hub and may be 
connected to it using an IEEE 802.3 network or may be directly plugged into the wireless hub's backplane. These 
devices will be referred to by the term trunk AP. 

3. Mixed AP architecture. In a mixed architecture, the wireless sub-network will have to support remote and local 
access points. Remote access points may be added for hole filling and other capacity reasons. As described earlier 
T1 or wireless trunks may be used to connect the remote AP to the wireless hub. 

[0046] FIG. 5 shows a cell with three sectors using local APs only. The access points and the wireless hub are co- 
tocaied in the base station and are connected to each other with 802.3 links. 

[0047] FIG. 6 shows an architecture with remote access points 82 connected to wireless hub 84 using wireless trunks 
86. Each trunk access point in the base station provides a point lo multi-point wireless radio link to the remote micro 
access points (R-AP in figure). The remote access points provide air link service to end systems. The wireless hub 
and the trunk access points are co-located in the base station and connected together via 802.3 links. This figure also 
shows remote access points 82R connected to the wireless hub via point to point Tl links. In this scenario, no trunk 
APs are required. 

[0048] To support all of the above cell architectures and the different typos of access points that each cell might use, 
the network architecture follows the following rules; 



1. Access points function as MAC layer bridges. Remote access points perform MAC bridging between the air link 
to the end systems and the wireless or T1 trunk to the cell site. Local access points perform MAC bridging between 

30 the air link to the end systems and the wireless hub. 

2. Trunk access points also function as MAC layer bridges. They perform MAC bridging between the trunk (which 
goes to the access points) and the wireless hub. 

^5 3. The wireless hub is connected to all co-located MAC bridges (i.e. local access points or trunk access points) 

using a 802.3 link initially. 

[0049] Additionally, where local access points or remote access points with T1 trunks are used, the following rules 
are followed. 

40 

1. Local access points are co-located with the wireless hub and connected to it using point to point 802.3 links or 
a shared 802.3 network. Remote access points are connected to the wireless hub using point to point T1 trunks. 

2. Sectorization is supported by adding access points with sectored antennas to the cell site 

45 

3. For each access point connected to the wireless hub, there is a foreign agent executing in the wireless hub 
which participates in end system registration. MAC layer association procedures are used to keep the MAC address 
filter tables of the access points up lo dale and lo perform MAC layer bridging eflicienlly. The wireless hub partic- 
ipates in MAC association functions so that only valid MAC addresses are added to the MAC address filter tables 

^o of the access points. 

4. The foreign agent in the wireless hub relays frames from the access points to the MSC IWF and vice versa using 
the x/unnc/ protocol. The MAC address filter table is used to filter out those unicast MAC data frames whose MAC 
addresses are not present in the table. The APs always forward MAC broadcast frames and MAC frames associ- 

55 ated with end system registration functions regardless of the contents of the MAC address filter table. 

5 Local access points use ARP to resolve MAC addresses for routing IP traffic to the wireless hub. Conversely, 
the wireless hub also uses ARP to route IP packets to access points. UDP/IP is used for network management of 
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access points. 



6. Remote access points connected via T1 do not use ARP since the link will be a point to point link. 

7. Support forhand-offs Is done with assistance from the MAC layer 

[0050] In a cell architecture using wireless trunks and trunk APs, the following rules are followed. 

ot^:::2ZT^nT "'^'^^^ '"'^ ^^""^'^•^^ '° « P°-' to pomt 8O2.3 imks or 

2. Wireless trunk sectorization is supported by adding trunk access points with sectored antennas to the cell site. 

MA^J aiTess'^nLMrhtr'S k T'"'""^'^ '''''' '^^"^ ^^^'""^ association and hand off procedures Their 
netl^The Mir hh , ^"^"^'^^"y Programmed by the wireless hub as end systems register with the 
network. The MAC address filter table is used to filter out unicast MAC frames Broadcast MAC frames or mao 
frames conlainmg registration packets are allowed to always pass through. ' ^^"^ ^'^"^^ °' 

hub'u^ TnlT ""T '^^""^ ""^^ addresses for routing IP traffic to the wireless hub. Conversely the wireless 
hub use ARP ,0 route IP packets to trunk APs. UDP/IP is used for network management of trunk ApI 

.t,i"MAcTive7w?hThr"' ""f h-d-o"s from one access point to another is done using 

the MAC layer with the assistance of the foreign agent in the wireless hub. Using these MAC layer orocedu/rs 

th. ""r'T """^ ^"'"'^ """^^ ^y^'^*^^ ''^ point to anoSerac^sfpoint' 

the c«;!;,/° h"' ^ '''''' ^^"^ °" ''^°'°'=°' '° "P^^t« ^^AC address filter tables Thrwireles^^^^^^^^^ 

ayertnnrsT/or?^^ "'^'^^'^ '° "^"^^^ '^'^ "^^^^ includes etying mac 

^.h ^ "^^^^^^9^^ a'^'^ess points will not be able to communicate direct^ over the MAC layer with 

7. The foreign agent for a wireless trunk sector is responsible for relaying frames from its trunk AP to th^ M<?r ^nH 
Z\ZZ:r' ".H ^'""^^'P-tocol. Thus, the foreign agent for a tU AP doeT'o clrLout the'^^^^^ 
foL«?H / r T*"^^' '° '^«t Wireless trunk sector. In the down link d rectSf it ius 

forwards frames from the tunnel to the appropriate trunk AP which uses MAC layer bridging"o send the Trames to 
es ^nn! ^"JT ^"^'^'"^ ^^'^tor. The access points consu? S MAC addresT fml° 

tS MAP HH ^r'"' ''^'"^^ ^'^'^^^^ "«t'«°rk or drop the MAC frames As described ab^Je 

nk difectS? MAP T '"P* ^° ^^'^ MAC layer association and hand off priSes Inthe up 

ink direction, MAC frames are forwarded by the access points to the backhaul bridge which fon«ards thPmVo ,h^ 
foreign agent in the wireless hub using the 802.3 link. 'onvards them to the 

rytt^m as~^^^^^^ ' — - access points a^nd for end 

rS '^^^^^'^"'^ard 802.3 links in the cell site may be replaced by other speed links 

LTr L V hT "^"^ ^ P°'"t- At "^^ "^^^^ °' tl^^ stack is physical layer PHY Physical 

layer PHY carries data to and from an end system over the air using radio waves as an exLple vE;ecLTd to^ 

jLTr,:' T' T T "'"^"^ '^'^^ P'^y^'<=^' '^y^^ and Unpacks it from the MAC ftm^rt^e M^ct^ 
The end systom data frames arc then repacked into an Ethernet physical layer format (IEEE 802 3^o matiwhcro ^i. 

Emern'S lint f' e r' T '° "'"'^^^ '''' ^"^^^ '^^ ^"'^ — ^ datLlom ,he w^eZ Vub 

Ethernet link (i.e., the physical layer), the data to be transmitted to an end system, the AP packs the data in a mldlm 

T^lnyX^r ' ' '^"'^ "^"^ '^^^^ " '° be transmitJd S the' entsys^erutng 

[00S3] In FIG 8, the MAC and PHY layers to/from the end system of FIG. 7 are replaced by a MAC and PHY for the 
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trunk to the cell site for a remote access point. Specifically for a T1 trunk, the high level data link control protocol (HDLC 
protocol) is preferably used over the T1 . 

[0054] FIG. 9 depicts the protocol stack for the wireless hub that bridges the backhaul tine and the trunk to the remote 
access point. The trunk to the remote APs are only required to support remote access points (as distinct from Ethernet 
coupled access points). The MAC and PHY layers for the wireless trunk to the remote APs provide a point to multipoint 
link so that one trunk nnay be used to communicate with many remote APs in the same sector 

[GCoSj The Vvire!ess liUu ui iciyes uiw It uiik io liie itJinoie AFs and Liie backriaui iine {e.Q., Ti or T3) to ihe network's 
mobile switching center (MSG). The protocol stack in the wireless hub implements MAC and PHY layers to the MSC 
on top of which is implemented an IP {Internet Protocol) layer on top of which is implemented a UDP layer (Universal 
Datagram Protocal, in combination referred to as UDP/IP) for network management on top of which is implemented 
an XTunnel protocol. The XTunnel protocol is a new format that includes aspects of mobility (e.g. as in mobile IP) and 
aspects of the Level 2 Tunnel Protocol (L2TP). The XTunnel protocol is used to communicate from the wireless hub 
to the MSC and between inter-working functions (IWFs) in different networks or the same network. 
[0056] In FIG. 10, the protocol stack for the relay function in the base station for supporting remote access points is 
shown. The relay function includes an interface to the backhaul line (depicted as the wireless hub) and an interface to 
the remote AP (depicted as a trunk AP). From the point of view of the wireless hub, the trunk AP (depicted in FIGS. 7 
and 10) actually behaves like the AP depicted in FIG. 7. Preferably, the base station protocol stacks are split up into 
a wireless hub and a trunk AP with an Ethernet in between. In an N-sector wireless trunk, there are N wireless trunk 
APs in the cell site and one wireless hub. 

[0057] In FIG. 11 , the base slalion protocol slack for a cell architecture using a local AP is shown. The relay function 
includes an interface to the backhaul line (depicted as the wireless hub) and an air link interface to the end system 
(depicted as an AP). From the point of view of the wireless hub, the AP (depicted in FIGS. 8 and 11) actually behaves 
like the trunk AP depicted in FIG. 8. Preferably, the base station protocol stacks are split up into a wireless hub and a 
trunk AP with an Ethernet in between. In a N-sector cell, there are N access points and a single wireless hub. 
[0058] The backhaul network from the base station to the MSC has tho following attributes. 

1. The network is capable of routing IP datagrams between the base station and the MSC. 

2. The network is secure. It is not a public internet. Traffic from trusted nodes only are allowed onto the network 
since the network will be used for not only transporting end system traffic, but also for transporting authentication, 
accounting, registration and management traffic. 

3. The network has the necessary performance characteristics. 

[0059] In typical application, the service provider is responsible for installing and maintaining the backhaul network 
on which the equipment is installed. 

[0060] The base stations supports the following backhaul interfaces for communicating with the MSC. 

1. Base stations support IP over PPP with HDLC links using point to point TI or fractional T3 links. 

2. Base stations support IP over frame relay using TI or fractional T3 links. 

3. Base stations support IP over AAL5/ATM using TI or fractional T3 links. 

4. Base stations support IP over Ethernet links. 

[0061] Since all of the above interfaces are based on IETF standard encapsulations, commercial routers may be 
used in Ihe MSC to terminate the physical links of the backhaul network. Higher layers are passed on and processed 
by the various servers and other processors. 

[0062] End system registration procedures above the MAC layer are supported. In the following, end system regis- 
tration procedures at the MAC layer are ignored except where they impact the layers above. 

[0063] End systems may register for service on their home network or from a foreign network. In both scenarios, the 
end system uses a foreign agent (FA) in the base station to discover a point of attachment to the network and to register 
In the former case, the FA is in the end system's home network. In the latter case, the FA is in a foreign network. In 
either case, the network uses an IWF in the end system's home network as an anchor point (i.e.. unchanging throughout 
the session in spite of mobility). PPP frames to and from the end system travel via the FA in the base station to the 
IWF in the home network. If the end system is at home, the home IWF is directly connected by means of the xtunnei 
protocol to the base station. Note that the home IWF may be combined with the base station in the same node. If the 
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Jp^inn rp T^' ^ '^"^ "^'^"^"^ connected to the home IWF over an Nnterface The 

rr.^ ^ ''''^^ ''"^ 'WF. Note that the home IWF may be combined 

wrth the base stat.on in the same node. From the home IWR data is sent to a PPP seiver which may resTin "he 

Sura, on '^^ °^ '=°^P°^^^^ different from the wireless servbe pj,6er For the 

duration of the session, the location of the home IWF and the PPP server remains fixed. If the end system moves whHe 
connected, it will have to re-register with a new foreign agent. However, the same home IWF and PPP se^rrTontiLes 

age^r/nd th: ^WF ^e^^cj eT"" "^'^ '^^ — — °^ "-"^ 

[0064] FIG. 1 2 shows this network configuration for two end systems A and B, both of whose home wireless network 
irZ'i r r"^'' ^"^^""'^^ ^^9'^'^^^^ home Wireless net^Iand thel^S 

LrsvIZfdr r'^:.? I'^ " ^^^^-^ ^^^^^ ^'^^ '^^'•^ systems. PorCh 

own«d h^cfp A M " T^^"" '° '"""^ ""^ '^^ '° ^^^'^^ Pfovder-s PPP server 

th^the hlnC:?wP^'^ iH rr^'' "^^^^ subscribed to the same ISP If that were not the case, 

then the home IWF would be shown also connected to another ISP 

^^nlnZ'!^,^nlTf ^^"'^f ""^'^ ''^^^^^ the IWF is carried using the 

^iZt? hi Data between the IWF and the PPP server is carried using Level 2 Tunneling Protocol (L2TP) Data 
between the serving IWF and the home IWF is carried using the l-xtunnel protocol 

Sica^aSfJ in'lh'°K ^ y'^' T^'" '^''"''"9 "''"^ function may be 

baseTJa^m ' ^^"^'"^ ^'^''^^'^^ ^ '°^'"'"9 '^^^ 

i^I^IJitu'^lT'H '""^^ advantages and disadvantages. An obvious advantage is 

rJ7o send ^„t'^*'^"*^9" °' '^^^•"S t° ^-^y data to and from a possibly remote home IWR The alternative 

or?ho r^r^ iwc r^'^T 'nformation to the serving IWF so that it may connect to the end system's ISP/intranet and 
?hil f uJcZ^ accounting information in noar real timo back to the accounting server in the home network 

lo L. rn ? ^ T """'^ '° "^P'«"^«nt, but more efficient because it reduces the need to relay data over 

potentially long distances from the foreign network to the home network 

£?n ChicronrnHT'"' °' ^ "^^^ "=>^<^^ Chicago to Hong Kong. If the user's home network 

l^hor n K M"? ' "^'"9 ^ ^^-^'ce Provider in Hong Kong, then in the first configuration the 

Tsa ThTh^e r,^:' rT " J'"'^" '^^^ ""^^^ '^""^ '<-9 to Chicago and vic^ 

versa. The honne IWF in Chicago will connect to the user's ISP in Chicago. With the second configuration the end 
system user will be assigned an ISP in Hong Kong. Thus, data will not always have to be relayS back aid fort^ 
chl:::"o?SuraT ■ configuration, the serving iJf will serve as the fnchor a"d nev^^^^ 

a rtsStt of .nH t T ^^^^ " "y'*^"' °f the FA may change as 

a result of end system movement in Hong Kong. 

S?Sf A i^d cllf T '^^ second network configuration. In this figure, the home network for end system A and B is 
A ulo theTstrS''' Tl:"""^ "''"9 '^"'^ ^" ^"'^hor point, and also connects to 

WF whtn«ir '^'^^f'^^^ End system B registers from the foreign network of WSP-B and uses a serving 
IWF which senses as the anchor point and connects the end system to an ISP using the ISP's PPP server In this 

Te veS"' ^ '"^^ '° "^'--"^ »° 'he home netwoli; Tnd 

tS.lnn wirof ' "''^ configuration to work, not only must there be roaming agreements between the home and 
andmreXJ, ''7'' "^^^ '^^ agreements between the foreign wireless service provider 

and the end system s internet service provider directly or through an intermediary In the example above, not only must 

but thrwsP irHono^K""" " 1r """^ '^^^ ^ '"""^^^ "^"^"^"^ -'-'-^ --^^ P--^- .n cmcago 

S^il PpTi!L"°"?,''°"9 '""^^ "^^^^ ^ ''"^'"^^^ agreement with the user's Chicago ISP and access to the Chicago 
InrTo . r ^"^ "9 or a business agreement with another ISP locally in Hong Kong who has a business 

..greemenl for roaming with the user' Chicago ISP Additionally, the WSP in Hong Kong must be able to discover these 
l^n^s ' """"^"'P^ dynamically ,n order to do user authentication and accounting and to set up the appropriate 

f!?hJ|pTl'f """^""'^^ those companies who are in the Internet infrastructure business to work out suitable standards 
1,^ , J , ^" °'.'hese scenarios. Thus, a preferable embodiment for the present systems to implement the simpler 
potentially less efficient configuration, whore the IWF in the home network is always used as the anchor point However 
in the presence of suitable industry standardization of protocols for Intemet roaming, the second configuration should 
be regarded as equivalent or alternative embodiment. 

^" l""* ^^^'^"^ ^^"^ '° '^9'=*®' "^"h the wireless network before it can start PPP and send and receive 
data. The end system first goes through the FA discovery and registration phases. These phases authenticate and 
register the end system to the wireless sen/ice provider Once these phases are over, the end system starts PPP This 
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includes the PPP link establishment phase, the PPP authentication phase and the PPP network control protocol phase. 
Once these phases are over, the end systenn is able to send and receive IP packets using PPP 
[0073] The following discussion assumes that the end system is roaming and registering from a foreign network. 
During the FA discovery phase, the end system (through its user registration agent) waits for or solicits an advertisement 

5 from the foreign agent. The user registration agent uses advertisement messages sent by a near by foreign agent to 
discover the identity of the FA and to register During this phase, the user registration agent of the end system selects 
a FA anci issucs a reyisiration reQuesl to it. Ti ie FA acling as a pioxy reyisiralion ageni forwards the regisiration request 
to its registration server (the registration server in the foreign WSP). The registration server uses User-Name from the 
user registration agent's request to determine the end system's home network, and forwards the registration request 

10 for authentication to a registration server in the home network. Upon receiving the registration request relayed by the 
foreign registration server, the home registration server authenticates the identity of the foreign registration server and 
also authenticates the identity of the end system. If authentication and registration succeeds, the home registration 
server selects an IWF in the home network to create an l-xtunnel\\nk between the home IWF and the serving IWF (in 
the foreign WSP). The IWF in the home network serves as the anchor point for the duration of the PPP session. 

15 [0074] Once the authentication and registration phases are over, the various PPP phases will be started. At the start 
of PPP. an L2TP connection is created between the home IWF and requested ISP/intranet PPP server. In the PPP 
authentication phase, PPP passwords using Password Authentication Protocol (PAP) or Challenge Authentication Pro- 
tocol CHAP are exchanged and the ISP or intranet PPP server independently authenticates the identity of the end 
system. 

20 [0075] Once this succeeds, the PPP network control phase is started. In this phase^ an IP address is negotiated and 
assigned to the end system by the PPP server and the use of TCP/IP header compression is also negotiated. When 
this is complete, the end system is able to send and receive IP packets using PPP to its ISP or a corporate intranet. 
[0076] Note that two levels of authentication are performed. The first authentication authenticates the identity of the 
end system to the registration server in the home network and the identities of the foreign network and the home 

25 network to each other To perform this function, the foreign agent forwards the end system's registration request using, 
for example, an IETF Radius protocol to a registration server in its local MSC in a Radius Access-Request packet. 
Using the end system's domain name, the foreign registration server determines the identity of the end system's home 
network and home registration server, and acting as a Radius proxy, encapsulates and forwards the request to the end 
system's home registration server If the foreign registration server cannot determine the identity of the end system's 

30 home, it may optionally forward the Radius request to a registration server that acts like a broker (e g. one that is owned 
by a consortium of wireless service providers), which can in turn proxy the Radius Access-Request to the final home 
registration server. If the local registration server is unable to service the registration request locally or by proxying, 
then it rejects the foreign agent's registration request and the foreign agent rejects the end system's registration request. 
Upon receiving the Radius Access-Request, the home registration server performs the necessary authentication of 

35 the identities of the foreign network and the end system. If authentication and registration succeeds, the home regis- 
tration server responds with a Radius Access-Response packet to the foreign registration server which sends a re- 
sponse to the foreign agent so that a round trip can be completed. The registration request is rejected if the home 
registration server is unable to comply for any reason. 

[0077] The second level of authentication verifies the identity of the end system to the intranet or ISP PPP server 
40 PPP authentication, separate from mobility authentication allows the infrastructure equipment to be deployed and 
owned separately from the^ISP 

[0078] FIG. 14 is a ladder diagram showing the registration sequence for a roaming end system. It is assumed that 
the PPP sen/er and the home IWF are in the same server and L2TP is not required. Note the interactions with accounting 
servers to start accounting on behalf of the registering end system and also directory servers to determine the identity 
^5 of the home registration server and to authenticate the end system's identity. More information on accounting, billing, 
roaming (between service providers) and settlement will be provided below. 

[0079] MAC layer messages from the user registration agent of the end system may be used to initiate Agent Solic- 
ilalion. The MAC layer messages are not shown for clarity. 

[0080] In FIG. 14, the end system (mobile) initially solicits an advertisement and the foreign agent replies with an 
50 advertisement that provides the end system with information about the network to which the foreign agent belongs 
including a care-of-address of the foreign agent. Alternatively, this phase may be removed and all network advertise- 
ments may be done by a continuously emitted MAC layer beacon message. In this case, the network is assumed to 
bo a foreign wireless service provider Then, a user registration agent (in the end system) incorporates the information 
about the foreign agent (including the user name and other security credentials) and its network into a request and 
55 sends the request to the foreign agent. The foreign agent, as a proxy registration agent, relays the request to the foreign 
registration server (i.e., the registration server for the foreign wireless service provider Then, the foreign registration 
server, recognizing that it is not the home directory, accesses the foreign directory server with the FDD in the foreign 
wireless service provider to learn how to direct the registration request to the home registration server of the wireless 
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service provider to which the end system belongs. The foreign registration server responds with the necessary for- 
warding information. Then the foreign registration sen/er encapsulates the end system's registration request in a Ra- 
dius access request and relays the encapsulated request to the home registration server of the wireless service provider 
to which the end system belongs. The home registration server accesses the home directory server with the HDD of 
the home registration server to learn at least authentication information about the foreign service provider Optionally 
the home registration server accesses the subscriber's directory to learn detail subscriber service profile Information 
(e.g.. quality of service options subscribed to, etc.). When all parties are authenticated, the home registration server 
senos a sian i wF request to the home IWF and PPP server. The home I WF and PPP sen/er starts the home accounting 
server and then sends a start IWF response to the home registration sen/er The home registration server then sends 
a Radius access response to the foreign registration server. The foreign registration server then sends a start IWF 
request to the sen/ing IWF server. The serving IWF server starts the serving accounting server and then sends a start 
IWF response to the foreign registration server. The foreign registration sen/er sends a registration reply to the foreign 
agent, and the foreign agent relays the registration reply to the end system. 

[CX)81] A link control protocol (LCP) configuration request Is send by the end system through the foreign registration 
server to the home IWF and PPP server The home IWF and PPP server sends an LCP configuration acknowledgment 
through the foreign registration server to the end system. 

[0082] Similarly, a password authentication protocol (PAP) authentication request is sent to and acknowledged by 
the home IWF and PPP server Alternatively, a challenge authentication protocol (CHAP) may be used to authenticate. 
Both protocols may be used to authenticate or this phase may be skipped. 

[0083] Similarly, an IP configuration protocol (IPCP) configure request is sent to and acknowledged by the home 
IWF and PPP server 

[0084] The connection to the end system may be terminated because of any one of the following reasons. 

1 . User initiated termination. Under this scenario, the end system first terminates the PPP gracefully. This includes 
terminating the PPP network control protocol (IPCP) followed by terminating the PPP link protocol. Onco this is 
done, the end system de-registers from the network followed by termination of the radio link to the access point. 

2. Loss of wireless link. This scenario is detected by the modem and reported to the modem driver in the end 
system. The upper layers of the software are notified to terminate the stacks and notify the user 

3. Loss of connection to the foreign agent. This scenario is detected by the mobility driver in the end system. After 
trying to reestablish contact with a (potentially new) foreign agent and failing, the driver sends an appropriate 
notification up the protocol stack and also signals the modem hardware below to terminate the wireless link. 

4. Loss of connection to the IWF. This is substantially the same as for loss of connection to the foreign agent. 

5. Termination of PPP by IWF or PPP sen/er This scenario is detected by the PPP software in the end system. 
The end system's PPP driver is notified of this event. It Initiates de-registration from the network followed by ter- 
mination of the wireless link to the access point. 

[0085] End system service configuration refers to the concept of configuring the network service for an end system 
based on the subscriber's service profile. The subscriber's sen/ice profile is stored in a subscriber directory. The service 
profile contains information to enable the software to customize wireless data sen/ice on behalf of the subscriber This 
includes inlormation to authenticate the end system, allow the end system to roam and set up connections to the end 
system's internet sen/ice provider Preferably this information also includes other parameters, like, quality of service, 
in addition to the subscriber directory, a home domain directory (HDD) and a foreign domain directory (FDD) are used 
for roaming and for authenticating the foreign and home registration servers to each other The HDD stores information 
about the end system's home network and the FDD stores information about foreign networks thai a subscriber may 
visit. 

[0086] FIG. 15 shows how these directories map into the network architecture and are used during registration for 
an end system that is registering at home, tn step 0 the end system (mobile) solicits and receives an advertisement 
from the foreign agent to provides the end system with information about the network to which the foreign agent belongs. 
In this case, the network Is the home wireless service provider In step 1, user registration agent (In the end system) 
incorporates the information about the foreign agent and Its network and its security credentials into a request and 
sends the request to the foreign agent. In step 2, the foreign agent, as a proxy registration agent, relays the request 
to the home registration server In step 3, the home registration sen/er accesses the HDD of the home wireless sen/ice 
provider to learn at least authentication information In step 4, the home registration sen/er accesses the subscriber 
directory to learn detail subscriber service profile information (e g , quality of sen/ice options subscribed to. etc ) In 
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step 5. the home registration server notifies the foreign agent of the access response. In steps 6 and 7. the foreign 
agent notifies the end system (i.e., mobile) of the registration reply. 

[0087] FIG. 16 shows directory usage for an end system that is registering from a foreign network. In step 0 the end 
system (mobile) solicits and receives an advertisement and the foreign agent advertises which provides the end system 

5 with information about the network to which the foreign agent belongs. In this case, the network is a foreign wireless 
service provider. In step 1, user registration agent (in the end system) incorporates the information about the foreign 
agent and its network and its security credential into a request and sends the request to the foreign agent. In step 2, 
the foreign agent, as a proxy registration agent, relays the request to the foreign registration server (i.e. , the registration 
server for the foreign wireless service provider. In step 3, the foreign registration server accesses the HDD of foreign 

10 wireless service provider to learn the network to which the end system belongs. In step 4, the foreign registration server 
forwards the end system's request to the home registration server of the end system's home wireless service provider 
In step 5, the home registration server accesses the FDD of the home registration server to learn at least authentication 
information about the foreign service provider In step 6, the home registration sen/er accesses the subscriber's direc- 
tory to learn detail subscriber service profile information (e.g., quality of service options subscribed to, etc.). In step 7, 

'5 the home registration server notifies the foreign registration server of the access response. In step 8, the foreign reg- 
istration server forwards to the foreign agent the access response. In step 9. the foreign agent notifies the end system 
(i.e.. mobile) of the registration reply. 

[0088] Protocol handling scenarios handle bearer data and the associated stacks for transporting bearer data to and 
from an end system. The protocol stacks for the cell architectures use local APs (FIG. 17) and remote APs (FIG. 18). 
20 [0089] FIG. 17 shows Ihe protocol slacks for handling communications between an end system (in its home network) 
and a home I WF for End System @ Home. FIG. 1 7 shows the protocol handling for a cell architecture where the access 
point and the wireless hub are co-located. 

[0090] FIG. 18 shows the protocol handling for a cell architecture where the access point is located remotely from 
the wireless hub. As shown, PPP terminates in the IWF and the configuration provides direct internet access' The 

25 configuration for the case where the PPP server is separate from the IWF is described later 

[0091] In FIG- 18, PPP frames from the end system are encapsulated in RLP (radio link protocol) frames which are 
encapsulated at the remote access point in MAC frames for communicating with the trunk access point (i.e., an access 
point physically located near the wireless hub), the remote access point being coupled to the access point by, for 
example, a wireless trunk). The access point functions as a MAC layer bridge and relays frames from the air link to 

30 the foreign agent in the wireless hub. The foreign agent de-en capsu tat es the RLP frames out of the MAC frames, and 
using the x/uhai©/ protocol, relays the RLP frames to the IWF. A similar, albeit reverse, process occurs for transmitting 
frames from the IWF to the end system. 

[0092] If the end system moves to another foreign agent, then a new xfunne/ will be automatically created between 
the new foreign agent and the IWF. so that PPP traffic continues to flow between them, without interruption. 
35 [0093] In the remote AP cell architecture (FIG. 18) using wireless trunks between the remote AP and the trunk AP, 
the air link between the end system and the access point may operate at a different frequency (f1) and use a different 
radio technology as compared to the frequency (f2) and radio technology of the trunk. 

[0094] FIG. 19 shows the protocol stacks for a roaming end system. The serving IWF uses of the /-xfunne/ protocol 
between the serving IWF and home IWF The rest of the protocol stacks remain unchanged and are not shown. This 

^0 architecture may be simplified by merging the serving IWF into the base station, thus eliminating the XWD protocol. 
[0095] The RLP layer uses sequence numbers to drop duplicate PPP datagrams and provide in-sequence delivery 
of PPP datagrams between the end system and the IWF It also provides a configurable keep-alive mechanism to 
monitor link connectivity between the end system and the tWF Additionally, in an alternative embodiment, the RLP 
layer also provides re-transmission and flow control sen/ices in order to reduce the overall bit error rate of the link 

•^5 between the end system and the IWF The RLP between the end system and the IWF is started at the beginning of 
the session and remains active throughout the session and even across hand-offs. 

[0096] In contrast to the specification in the mobile iP RFC (RFC 2003), IP in IP encapsulation is not used for tunneling 
between the foreign agent and the home IWF instead a new tunneling protocol, implemenled on top of UDP is used. 
This tunneling protocol is a simplified version of the L2TP protocol. The reasons for this choice are as follows. 

50 

1. The encapsulation protocol specified in RFC 2003 does not provide flow control or in-sequence delivery of 
packets. The presently described network may need these services in the tunnel over the backhaul. Flow control 
may be needed to reduce the amount of retransmissions over the air link because of packet loss duo to flow control 
problems over the network between the base station and the MSG or because of flow control problems in the base 
S5 station or the IWF 

2 By using a UDP based tunneling protocoL the 'mplementation can be done at the user level and then put into 
the kernel for performance reasons, after it has been debugged 
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traffic load over multiple links between the base station and the IVISC. 
4. ,n order to implement IP in ,P encapsulation as spea«ed in B^^^^^^^^^^ 

code, in cor^mercia, operating systems^-u-^^^^^^^ ,p .^^^^ 

ment manufacturers, Purchasing the TCP/IP stack from a v^"" « , ^ ^-^pyiP stack. This 

mobile IP tunneling would require a developer to continue supporting a variant version ot 

adds cost and risk. 

10097] While it is noted ,ha, the tunneling protocol ^^"^^^ 

L wireless service provider will not be able to ^nd ma ch equ^^^^^^^^^^ ^ ^^^.p. 

standard tunneling protocol within a single wireless service provider networK ira p 

ment from other vendors. heavyweight tunneling protocol so that 

p Js", sylen! IS ov.«,«d The new xtunne, prMoco, h.e me ,o.o»,n9 .ea,>„es, 

and to create the tunnel. 

. The .,.ua,.n .e„e, . a.,e ,o *,e^,. me ^UJ. Zr:::'.^::^^^^'^''^^'^^ 
address and therefore, to a different son/or in the MSG. This pcrmns mo y 
^cfoss muliple IWF servers and to provKJe different QOS to various users. 

3.Thex™,pro.c.o,supportsin-bandcontro.messag^^^^^^^^^^^^ 

4 The .unne, protocol sinds payload data over the tunneling media, for example, UDP/.P. The .unne, protocol 
supports flow control and in-sequence packet delivery. 

5 The xt.nne/protoco. may be implemented over media other than UDP/IP for qualHy of service. 
tOOS.] The network suppo.s direct -ernet c^^^^^^^^^^^^^^ 

rnTr:trp::r(S;^^^ 

^Tii,°"ThI- network supportsafirst configuration forawirel^^^^^^^^^^^^^ 

liderln this configuration, the home IWF in the MSG -^^^l^^^^^^^:^^^^^^^ network, 
routing protocols like RIP and uses a router o 'J^^,^^^^^^ provider who wishes to allow end systems 

10101] The network supports a second "^^^ 'S^^^^^f j J^^^^^^^^^^^ itself is not ISPs, or because the WSP 

to connect to one or more internet service P^^^'^^^,^^^^^^^^^^^^^^^ a wireless sen/ice provider may elect 

has agreements with other ISPs to P^°^'^^/<=<=^"^" a 3'- party ISP to allow the user who also 
to Offer network access to an end user and ^^V .^^av^^J^J^reem^^^ ^ oonfiguraUon, Ihe PPP server 

has an .ccounl wilh the 3^ p.rly '^^^ /-f^^^ '^f^^ ° J^^^^^ l,„ing protocol like L2TP (Layer Two Tunneling 
does not run in the ^0 shows the protocol stacks for this configuration for 

Protocol) is used to tunnel back to the ISP s PPK sen/er. n^j. 

an end system that is at home. ^.^^^ throughout the PPP session. Also the 

r0102] The location of the home IWF and the ISP HMK serve ^^^hout the PPP session. The physical link 

Uplnnel between the IWF and the ISP's PPP J ,37,^^;^^^^^^^^ relay or ATM network. The 

between the IWF and the PPP sewer is via a ^^'"^ ^.^^^^^^^^^ ^^e architecture. 

actual nature of the physical link is not important from "^%P° °' ° ppp sen/er resides in the corporate 

[0103] This configuration also supports intranet access. For intranet access, tne 

intranet and the home IWF uses L2TP to tunnel to it ^^^^^ P,q wilh the 

[0104] For a fixed end system, the protocol handling for intranet or it>K a 
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difference that the roaming end system uses a serving I WF to connect to its home IWR The protocol handling between 
a serving IWF and a home IWF has been described earlier In Figure 20, the home IWF may be merged into the wireless 
hub eliminating the X-Tunnel protocol. Also, the serving IWF may be merged into the wireless hub. thus eliminating 
the X-Tunnel protocol. 

s [0105] FIG. 21 shows the protocol stacks used during the registration phase (end system registration) for a local AP 
cell architecture. The stack for a remote AP cell architecture is very similar. 

[01 GC] The scenario SMOVvn above is for a roaiTiii"ig eiid sysieiVi. For aii 6iiu sysieio al iiOfne, iheie is no foreiyn 
registration server in the registration path. 

[0107] Note the mobility agent in the end system. The mobility agent in the end system and foreign agent in the 
10 wireless hub are conceptually similar to the mobile IP RFC 2002. The mobility agent handles network errors using 

time-outs and re-trys. Unlike the known protocol stacks for bearer data, RLP is not used. The foreign agent and the 

registration servers use Radius over UDP/IP to communicate with each other for registering the end system. 

[0108] Several aspects of security must be considered- The first, authenticating the identities of the end system and 

the foreign/home networks during the wireless registration phase. Second, authenticating the identity of the end system 
'5 with its PPP server during the PPP authentication phase. Third, authentication for storing accounting data, for billing 

and for updating home domain information. Fourth, encryption of bearer traffic transmitted to and from the end system. 

Fifth, encryption for exchanging billing information across service provider boundaries. 

[01 09] Shared secrets are used to authenticate the identity of end systems with their home networks and the identity 

of the home and foreign networks with each other during wireless registration. 
20 [0110] End system authentication uses a 128-bit shared secret lo create an authenticalor for its registration request. 

The authenticator is created using the known MD5 message digest algorithm as described in the mobile IP RFC 2002. 

Alternatively, a different algorithm may be used. The shared secret is not sent in the registration request by the end 

system. Only the authenticator is sent. On receiving the registration request from the end system, the home registration 

server re-computes the authenticator over the registration request data using the shared secret. If the computed au- 
25 thcnticator value matches the authenticator value sent by the end system, the homo registration server allows the 

registration process to proceed. If the values do not match, the home registration server logs the event, generates a 

security violation alarm and a nak (i.e., a negative acknowledgment) to the request. 

[0111] In the registration reply, the home registration server does the same - that is to say, uses the shared secret 
to create an authenticator for the registration reply that it sends to the end system. Upon receiving the reply, the end 

30 system re-computes the authenticator using the shared secret. If the computed value does not match the authenticator 
value sent by the home registration server in the reply, the end system discards the reply and tries again. 
[0112] These network security concepts are similar to the concepts defined in mobile IP RFC 2002. According to the 
RFC, a mobility security association exist between each end system and its home network. Each mobility security 
association defines a collection of security contexts. Each security context defines an authentication algorithm, a mode, 

35 a secret (shared or public-private), style of replay protection and the type of encryption to use. In the context of the 
present network, the end system's User-Name (in lieu of the mobile IP home address) is used to identify the mobility 
security association between the end system and its home network. Another parameter, called the security parameter 
index (SPI), is used to select a security context within the mobility security association, in a basic embodiment of the 
invention, only the default mobile IP authentication algorithm (keyed-MD5) and the default mode ("prefix+suffix") are 

•^0 supported with 128-bit shared secrets. Network users are allowed to define multiple shared secrets with their home 
networks. The mechanism for creating security contexts for end users, assigning an SPI to each security context and 
for setting the contents of the security context (which includes the shared secret) and for modifying their contents are 
described below. During registration, a 128-bit message digest is computed by the end system in prefix+suffix mode 
using the MD5 algorithm. The shared secret is used as the prefix and the suffix for the data to be protected in the 

•^5 registration request. The authenticator thus computed, along with the SPI and the User-Name are transmitted in the 
registration request by the end system. Upon receiving the end system's registration request, the foreign registration 
server relays the request along with the authenticator and the SPI, unchanged to the home registration server Upon 
receiving the registration request directly from the end system or indirectly via a foreign registration server the home 
registration server uses the SPI and the User-Name to select the security context. The home server re-computes the 

^0 authenticator using the shared secret. If the computed authenticator value matches the value of the authenticator sent 
in the request by the end system, the user's identity will have been successfully authenticated. Otherwise, the home 
registration server naks (negatively acknowledges) the registration request sent by the end system. 
[Oil 3] The registration reply sent by the homo registration server to the end system is also authenticated using the 
algorithm described above. The SPI and the computed authenticator value is transmitted in the registration reply mes- 

55 sage by the home server to the end system. Upon receiving the reply the end system re-computes the authenticator. 
and if the computed value does not match the transmitted value, it will discard the reply and retry 
[0114] The user's end system has to be configured with the shared secret and SPIs for all security contexts that the 
user shares with its registration server(s). This configuration information is preferably stored in a Win 95 registry for 
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Windows 95 based end systems. During registration, this information is accessed and usedfor authentication purposes^ 
railT In the network Radius protocols are used by foreign agent FA to register the end system and to configure 
Z lnne TeX^^^^^^^^ wireless hub and the home and serving IWFs on behalf of the end system. On receiving a 
egiiaTon request from the end system, the FA creates a Radius Access-Request packet^ stores its ow" attrO^utes 
Intote packet, copies the end system's registration request attributes unchanged into this packet and sends the 
combined reauest to the reqistration server in the MSG. d^^;..^ 
raiTe Radius authenticaL requires that the Radius client (in this case, the FA in the base and the Ra^ 

se"e (in this case tne registraton server in the MSO share a secret for authentication purposes. Thjs shared secret 
fs Z iTs^d to encrypt any private infomiation communicated between the Radius client and the Radius server. The 
ha red sec^Us a configurable parameter. The network follows the recommendations in the Radius RFC a^d uses the 
shared secret and the MD5 algorithm for authentication and for encryption, where encryption is needed. The Radius 
Accei ReTuest packet sent by the FA contains a Radius User-Name attribute (which ^'''''''TTlL'^Ie a^l 
Zd\ Radius User-Password attribute The value of the User-Password attribute is also a configurable value and 
TncrypS in hfj; re^^^^^^^^ by the Radius protocol. Other network specific -"ributes wf^ch are nc^^andar^^ 
aSutes from the point of view of the Radius RFC standards, are encoded as vendor specific Radius attributes and 

toTl^ %^roTo;";'a^^^^^^ sent by the FA to its registration server in the Radius Access-Request packet. 

1. user-Name Attribute. This is the end system's user-name as supplied by the end system in its registration 
request. 

2 User-Passv^ord Attribute. This user password is supplied by the base station/wireless hub on behalf of the user^ 
ft is encoded "rdescribed in the Radius EFC using the secret shared between the base statin and its registration 

server. 

3. NAS-Port. This is the port on the base station. 

4. NAS-IP-Address. This is the IP address of the base station. 

5. Service-Type This is framed service. 

6. Framed Protocol This is a PPP protocol. 

7. Xtur^r^e, Protocol Parameters. These pararr^eters are sent by the base station to ^^^^^^'^ 
sary to set up the xJunna/ protocol on behalf of the end system. This is a vendor-specific attribute. 

8. AP-IP-Address. This is the IP address of the AP through which the user is registering. This is a vendor-specific 
attribute. 

9. AP-MAC-Address. This is the MAC address of the AP through 10. 

10. End system's Registration Request. The registration request from the end system is copied unchanged into 
this vendor specific attribute. 

[01181 The following attributes are sent to the FA from the registration server in the Radius Access-Response packet. 

1 . Sen/ice Type. This is a framed service. 

2. Framed-Ptotocot. This is a PPP. 

3 3 Xtur^nel Protocol Parameters. These parameters are sent by the registration sen/er to ^^f"^"^^^^^"^^'^'^ 
necessary to set up the xtunr^el protocol on behalf of the end system. This is a vendor-spec.f.c attribute. 

4. Home Registrator. Server's Reg.strat,on Repfy. This attribute is sent to the FA from the ^^^^^l^^f^^^^^^^^^ 
The FA relays this attnbute unchanged to the end system in a registration reply packet. If there is a 'o;e'g" ^9-^ 
Jaton serSr in the path, this attribufe is relayed by it to the FA unchanged. I. is coded as a vendor-specific attribute. 

[0119] To provide sen/ice to roaming end systems, the foreign network and the home network are authenticated to 
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each other for accounting and billing purposes using the Radius protocol for authentication and configuration. This 
authentication is performed at the tinne of end systenn registration. As described earlier, when the registration server 
in the foreign network receives a registration request from an end system (encapsulated as a vendor specific attribute 
in a Radius-Access Request packet by the FA), it uses the end system's User-Name to determine the identity of the 
end system^s home registration server by consulting Its home domain directory HDD. The following information is stored 
in home domain directory HDD and accessed by the foreign registration server in order to forward the end system's 
reyisUaliort lequesi. 

1. Home Registration Server IP Address. This is the IP address of the home registration server to forward the 
registration request 

2. Foreign Registration Server Machine Id. This is the machine ID of the foreign registration server in SMTP (sim- 
plified mail transfer protocol) format (e.g., machine @fqdn where machine is the name of the foreign registration 
server machine and fqdn is the fully qualified domain name of the foreign registration server's domain). 

3. Tunneling Protocol Parameters. These are parameters tor configuring the tunnel between the serving IWF and 
the home IWF on behalf of the end system. These include the tunneling protocol to be used between them and 
the parameters for configuring the tunnel. 

4. Shared Secret. This is the shared secret to be used for uthentlcalion between the foreign registration server 
and the home registration server. This secret is used for computing the Radius User-Password attribute in the 
Radius packet sent by the foreign registration server to the home registration server. It is defined between the two 
wireless service providers. 

5. User-Password. This is the usor password to be used on behalf of the roaming end system. This user password 
is defined between the two wireless service providers. This password is encrypted using the shared secret as 
described in the Radius RFC. 

6. Accounting Parameters. These are parameters for configuring accounting on behalf of the end system that is 
registering. These parameters are sent by the registration server to its IWF for configuring accounting on behalf 
of the end system. 

[0120] Using this information, the foreign registration server creates a Radius Access-Request, adds its own regis- 
tration and authentication information into the Radius Access-Request, copies the registration information sent by the 
end system unchanged into the Radius Access-Request and sends the combined request to the home registration 
server 

[0121] Upon receiving the Radius-Access Request from the foreign registration server (for a roaming end system) 
or directly from the FA (for an end system at home), the home registration server consults its own directory server for 
the shared secrets to verify the identity of the end system and the identity of the foreign registration server in a roaming 
scenario by re-computing authenticators. 

[0122] After processing the request successfully, the home registration server creates a Radius Access-Accept re- 
sponse packet and sends it to the foreign registration server if the end system is roaming, or directly to the FA from 
which It received the Radius Access-Request. The response contains the registration reply attribute that the FA relays 
to the end system. 

[01 23] If the request can not be processed successfully, the home registration server creates a Radius Access-Reject 
response packet and sends it to the foreign registration server if the end system is roaming, or directly to the FA from 
which it received the Radius Access-Request. The response contains the registration reply attribute that the FA will 
relays to the end system. 

[0124] In a roaming scenario, the response from the home registration server is received by the foreign registration 
server. It is authenticated by the foreign registration server using the shared secret. After authenticating: the foreign 
registration server processes the response, and in turn, it generates a Radius response packet (Accept or Reject) to 
send to the FA. The foreign registration server copies the registration reply attribute from the home registration server=s 
Radius response packet, unchanged, into its Radius response packet. 

[0125] When the FA receives the Radius Access-Response or Radius Access-Reject response packet, it creates a 
registration reply packet using the registration reply attributes from the Radius response, and sends the reply to the 
end system, thus completing the round trip registration sequence. 

[0126] Mobile IP standards specifies that replay protection for registrations are implemented using time stamps, or 
optionally, using nonces However, since replay protection using lime stamps requires adequately synchronized time- 
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using nonces even though replay protect.on ^^^^ J^^^" 33 alternative erribodiment is envis.oned. 

password) between the end system and .is PPP ^^-^^ J^^'^jf ^^^^ gP to independently verify the identity of the user 
mecnan.sms described earlier ^^'^-''^T'^';:^^^^^^ beL with respect to accounting secur.ty 

r01 29] Authentication for accounting and directo^ f^^.^Hame MSG need not be authenticated. 
Access to directory sen/ers from network «?"'P^";^^"' "^J^^ end systerr. and the home IWF. End systems 

[0130] The network supports encryption of bearer da a sen^^^^^^ 

negotL encn^ption to be on oroff by f JP^^^P^Uo^^^^^^^^^^^^ based upon the security context, in add.uon 
the home registration server grants the f yXI^ecS and s^Te of replay protection, the security context .s a so 
to storing the authentication algorithm, ^.^^^.^^^^/f.^e'^l^^^ is negotiated between the end system and the 
used to specify the style of encryption algorrthm ^° '^/"^^^^^^ encapsulation ,n RLR ^ 
home agent, then the complete PPP frame is so ^^^^^^^^^1 part of the same trusted domain .n the MSG. These 
10131] The IWF, the accountlr^g server ^"^^^ ' '"^oSuTted intranet owned and operated by the wireless sen^.ce 
Entitles are either connected on the same LAN P^^^J ^^^'^ 3,,,,,,ng server and between the accounting 

-rr^nrr^s 

device. , iWF and the home IWF in the network. Accounting data collected 

101331 Accounting data is collected by the -^^'"9 '^^^^^'J^^J^pe MSG. Accounting data collected by the home 
Ly tho serving IWF is sent to an -^^.^l^^^^^^;^^^^^^^^^ data collected by the serving IWF is used 

,WF is sent to an accounting server .n the '^^ ' Jf^^ent of bills across wireless sen/ice provider bound- 

by the foreign wireless sen^ice provider for -"^'^-S^^^^^^^;^^^^^^^^^^^ by the home IWF is used for billing the end user 

and the foreign 

Sii'xtrrr^^^^^^^^ 

for the use of foreign networks. „,^,erablv use the Radius accounting protocol for sending accounting 

^BrsTco^nSngtr^^^^^^^ -^-^'^ 
accounting data to minimize risk of loss of ^'^^^^^^^^'S^Pnptti uses re-trys based on acknowledgment and time outs^ 
101 36] The Radius accounting P-»°<;°^;""X;^^Xp^^ accounting request packets to their accounting 

The Radius accounting client (serving IWFs or home 'Whs, s 
.0 lexers which send acknowledgments back .0 J^^^ ^^n^'t^tho^ ,WF) em« an accounting start indication a. 
[01 37] in the network, the accounting clients (^^^'"S 'T^^^^ j^e end of the user's session. In the middte of the 
he stirt Of the user's session and an --'^^""^'"a ^^TkXu^^^^^^ contrast, the Radius accounting RFG does 

session, the accounting clients emit accounting "^P^^^^^""^^^^^^ , system creates a vendor specitK: account- 

not specify an accounting checkpoint ^^^^'^'^^J'^'^l'f''^^^^^^^ a5 Radius Accounting-Request packets which have 
.5 ing attribute for this purpose. This ^.^^^^^'^^^"^^^^^^^^^ ^'^^I'^Z of this attribute is used to convey to t^e accoun^g 
Acct-Status-Type of Start (accounting start '"^caUc^nsV^^^^^^^ Check-pointing accounting reports have a time 

server whether the accounting record is ^^^^^^^^^^^^^^^'^^^^ „ .^e session. The frequency ol transmitting check- 
allribule and contain cumulalive accounting data from the sia 

DOint packets is configurable in the present invention. respective registration servers for connecting to 

fo 38] The serving IWF and the home IWF are <=°;\9^^^^X"^^^^ ^T"". 
Lir accounting severs dunng the ^^^^^^:^::ZT.lJoi^^^^ the ses^on/multi-session id and the shared 
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user and is present in all accounting reports. The format is "user domain'* where domain is the fully qualified 
domain name of the user's home. 

2. NAS IP Address. This is like the Radius NAS-IP-Address attribute discussed above. This attribute is used to 
5 identify the IP address of the machine running the home 1 WF or the serving IWR 

3. Radio Pan, This aiif ibule ideniiNes irie radio port on ihe access point providing service lo the user This attribute 
is encoded as a vendor specific attribute. 

10 4. Access Point IP Address. This attribute identifies the IP address of the access point providing service to the 

user. This attribute is encoded as a vendor specific attribute. 

5. Sen/ice Type. This is like the Radius Service-Type attribute described above. The value of this attribute is 
Framed. 

IS 

6. Framed Protocol. This is like the Radius Framed-Protocol attribute described above. The value of this attribute 
is set to indicate PPP 

7. Accounting Status Type. This is like the Radius Acct-Status-Type attribute described above. The value of this 
20 attribute may be Start to mark the start of a user's session with the Radius client and Slop to mark the end of the 

user's session with the Radius client. For accounting clients, the Acct-Status-Type/Start attribute is generated 
when the end system registers. The Acct-Status-type/Stop attribute is generated when the end system de-registers 
for any reason. For checkpoints, this value of this attribute is also Start and the Accounting Checkpoint aXXnbuXe is 
also present. 

25 

8. Accounting Session Id. This is like the Radius Acct-Session-ld described above. In a roaming scenario, this 
session id is assigned by the foreign registration server when the end system issues a registration request. It is 
communicated to the home registration server by the foreign registration server during the registration sequence. 
The home network and the foreign network both know the Acct-Session-ld attribute and are able to emit this 

30 attribute while sending accounting records to their respective accounting servers. In a "end system-at-home" sce- 

nario, this attribute is generated by the home registration server. The registration server communicates the value 
of this attribute to the IWF which emits it in all accounting records. 

9. Accounting Multi-Session Id. This is like the Radius Acct-Multi-Session-ld discussed above. This Id is assigned 
55 by the home registration server when a registration request is received from a FAdirectly or via a foreign registration 

server on behalf of an end system. It is communicated to the foreign registration server by the home registration 
server in the registration reply message. The registration server(s) communicates the value of this attribute to the 
IWF(s) which emit it in all accounting records. 

40 [0140] With true mobility added to the architecture, the id is used to relate together the accounting records from 
different IWFs for the same end system if the end system moves from one IWF to another. For hand-off s across IWF 
boundaries, the Acct-Session-ld is different for accounting records emanating from different IWFs. However, the Acct- 
Multi-Session-ld attribute is the same for accounting records emitted by alt IWFs that have provided service to the user. 
Since the session id and the mutti-session id are known to both the foreign network and the home network, they are 

-'^ able to emit these atthbutes in accounting reports to their respective accounting servers. With the session id and the 
multi-session id, billing systems are able to correlate accounting records across IWF boundaries in the same wireless 
service provider and even across wireless service provider boundaries. 

1. Accounting Delay Time. See Radius Acct-Delay-Time attribute. 

so 

2. Accounting Input Octets. See Radius Acct-lnput-Octets. This attribute is used to keep track of the number of 
octets sent by the end system (input to the network from the end system). This count is used to track the PPP 
frames only The air link overhead, or any overhead imposed by RLR etc. is not counted. 

55 3. Accounting Output Octets. See Radius Acct-Output-Octets. This attribute is used to keep track of the number 

of octets sent to the end system (output from the network to the end system). This count is used to track the PPP 
frames only The air link overhead, or any overhead imposed by RLR etc and is not counted. 
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[0143] In FIG. 22, the raw accounting data received by the accounting server from ^he home or serving IWFs are 
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processed and stored by the accounting server. The processing done by the accounting server includes filtering, com- 
pression and corretrition of the raw accounting data received from the IWF A high availability file server using dual 
active/standby processors and hot swappabte RAID disks is used for buffering the accounting data while it is transiting 
through the accounting server. 

[0144] The accounting server delays processing of the raw accounting data until an end system has terminated its 
session. When an end system terminates its session, the accounting server processes the raw accounting data that 
it MoS concCted for the ScSSion anci SiOi 66 cxi'i accouritii iy suiTimcny recoiu il l a SOL cialabase;. Tiie accounitny summary 
record stored in the SQL data base points to an ASN. 1 encoded file. This file contains detailed accounting information 
about the end system's session. The data stored in the accounting server is then transferred by the billing data transfer 
agent to the customer's billing system. Alternatively, the wireless service provider may transfer the accounting data 
from the SQL database and/or the ASN.1 encoded file to the billing system via a tape. The data base scheme and the 
format of the ASN.1 encoded file are documented and made available to customers for this purpose. If the volume of 
processed accounting data stored in the accounting system exceeds a high water mark, the accounting server gener- 
ates an NMS alarm. This alarm is cleared when the volume of data stored in the accounting server falls below a low 
water mark. The high and low water marks for generating and clearing the alarm are configurable. The accounting 
server also generates an NMS alarm if the age of the stored accounting data exceeds a configurable threshold. Con- 
versely, the alarm is cleared, when the age of the accounting data falls below the threshold. , 
[0145] The subscriber directory is used to store information about subscribers and is located in the home network. 
The home registration server consults this directory during the registration phase to authenticate and register an end 
system. For each subscriber, the subscriber directory stores the following information. 

1. User-Name. This field in the subscriber record will be in SMTP format (e.g., user@fqdn) where the user sub- 
field will identify the subscriber in his or her wireless home domain and the fqdn sub-field will identify the wireless 
home domain of the subscriber. This field is sent by the end system in its registration request during the registration 
phase. This field is assigned by tho wireless service provider to the subscriber at the time of subscription to the 
network service. This field is different than the user name field used in PPP. 

2. Mobility Security Association. This field in the subscriber record contains the mobility security association be- 
tween the subscriber and his or her home network. As described above, a mobility security association exists 
between each subscriber and its home registration server The mobility security association defines a collection 
of security contexts. Each security context defines an authentication algorithm, an authentication mode, a shared 
secret, style of replay protection and the type of encryption (including no encryption) to use between the end system 
and its home server. During registration, the home registration server retrieves information about the subscriber's 
security context from the subscriber directory using the User-Name an(^ the security parameter index (SPI) suppWed 
by the end system in its registration request. The information in the security context is used for enforcing authen- 
tication, encryption and replay protection during the session. The mobility security association is created by the 
wireless service provider at the time of subscription. It Is up to the wireless service provider to permit the subscriber 
to modify this association either by calling up a customer service representative or by letting subscribers access 
to a secure Web site. The Web site software will export web pages which the wireless service provider may make 
accessible to subscribers from a secure web server. In this way, subscribers are able to view/modify the contents 
of the mobility security association fn>addition to other subscriber information that the service provider may make 
accessible. 

3. Modem MAC Address. This field contains the MAC address of the modem owned by the subscriber In addition 
to the shared secret, this field is used during registration to authenticate the user It is possible to turn off MAC 
address based authentication on a per user basis. The MAC address is communicated to the home registration 
server during registration. 

4. Enable MAC Address Authentication. This field is used to determine if MAC address based authentication is 
enabledor disabled. If enabled, the home registration serverchecks the MAC address of the registering end system 
against this field to validate the end system's identity. If disabled, then no checking is done. 

5. Roaming Enabled Flag. If this field is sot to enabled, then the end system is allowed to roam to foreign networks. 
If this field is disabled, then the end system is not permitted to roam to foreign networks. 

6. Roaming Domain List. This field is meaningful only if the Roaming Enabled Flag is set to enabled. This field 
contains a list of foreign domains that the end system is allowed to roam to. When the contents of this list is null 
and the Roaming Enabled Flag is set to enabled, the end system is allowed to roam freely 
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7. Sen/ice Enable/Disable Flag. This field may be set to disabled by the system administrator to disable service 
to a subscriber If this field is disabled, then the subscriber is permitted to register for service. If the subscriber is 
registered and the value of this field is set to disabled, then the subscriber's end system is immediately disconnected 
by the network. 

8. internet Service Provider Association. This field contains information about the subscriber's internet service 
provider. This information is used by the I WF during the PPP registration phase to perform authentication with the 
internet sen/ice provider on behalf of the end system and also to create a L2TP tunnel between the I WF and the 
internet service provider's PPP server. This field contains the identity of the subscriber's ISR The IWF uses this 
information to access the ISP directory for performing authentication and setting up the L2TP tunnel on behalf of 
the end system. 

9. Subscriber's Name & Address Information. This field contains the subscriber's name, address, phone, fax. e- 
mail address, etc. 

[0146] The home domain directory (HDD) is used by the registration server to retneve parameters about the end 
system to complete registration on behalf of the end system. Using this information, the registration server determines 
if the end system is registering at home or if the end system is a roaming end system, in the former case, the registration 
server assumes the rote of a home registration server and proceed with end system registration. In the latter case, the 
registration server assumes the rote of a foreign registration server and, acting as a Radius proxy, it fonrt/ards the 
request to the real home registration server whose identity it gets from this directory. For roaming end system, the 
parameters stored in the HDD include the IP address of the home registration server, the home-foreign shared secret, 
the home-serving IWF tunnel configuration etc. The HDD is located in the MSG. 
[0147] The following information is stored in the HDD. 

1 . Home Domain Name. This field is used as the key to search the HDD for an entry that matches the futly qualified 
home domain name provided by the end system in its registration request. 

2. Proxy Registration Request. This field is used by the registration server to determine if it should act as a foreign 
registration sen/er and proxy the end system's registration request to the real home registration sen/er 

3. Home Registration Sen/er DNS Name. If the proxy registration requestnag is TRUE, this field is used to access 
the DNS name of the real home registration server. Othenwise. this field is ignored. The DNS name is translated 
to an IP address by the foreign registration server. The foreign registration server uses the IP address to relay the 
end system's registration request. 

4. Foreign Domain Name. If the proxy registration request nag is TRUE, this field is used to identify the foreign 
domain name to the end system's home registration sen/er. Otherwise, this field is ignored. The foreign registration 
server uses this information to create the foreign server machine id in SMTP format, for example, machine @fqdn. 
This machine id is sent to the home registration server by the foreign registration server in the Radius-Access 
Request. 

5. Shared Secret. If the proxy registration requesti\ag is TRUE, the shared secret is used between the foreign and 
home registration servers to authenticate their identity with each other. Othenwise this field is ignored. 

6. Tunneling Protocol Parameters, This field is used to store parameters to configure the tunnels to provide service 
to the end system. For an end system at home, this includes information on tunnel parameters between the base 
station and the home IWF and from the home IWF to the PPP server. For a roaming end system, this includes 
tunneling parameters from the base station to the serving IWF and from the serving IWF to the home IWF At a 
minimum, for each tunnel, this field contains the type of tunneling protocol to use and any tunneling protocol specific 
parameters. For example, this field may contain the identifier for the tunneling protocol L2TP and any additional 
parameters required to configure the L2TP tunnel between the IWF and its peer. 

7. Accounting Sen/er Association. This field is used to store information needed by the IWF to generate accounting 
data on behatf of the end system. It contains the name of the accounting protocol (e.g. RADIUS), the DNS name 
of the accounting server and additional parameters specific to the accounting protocol like the UDP porl number, 
the shared secret that the IWF must use in the Radius Accounting protocol, the frequency of check-pointing, the 
seed for creating the session/mutti-session id. etc The accounting server's DNS name is translated to the account- 
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ing server's IP address, which is sent to the IWF. 

[0148] For wireless service providers that have roaming agreements with each other, the HDD is used for authenti- 
cation and to complete the registration process. If an end system roams from its home network to a foreign network, 
the foreign registration server in that network consults the HDD in its MSC to get information about the visiting end 
system's home registration and to authenticate the home network before it provides service to the visiting end system. 
[0149j The soiiware for home domain directory management prererabiy provides a grapnical user intertace (GUI) 
based HDD management interface for system administrators. Using this GUI, system administrators are able to view 
and update entries in the HDD. This GUI is not intended for use by foreign wireless network service providers to perform 
remote updates based on roaming agreements. It is only intended for use by trusted personnel of the home wireless 
service provider operating behind fire walls. 

[0150] The foreign domain directory (FDD) provides functionality that is the reverse of the home domain directory. 
The FDD is used by the home registration server to retrieve parameters about the foreign registration server and the 
foreign network in order to authenticate the foreign network and create a tunnel between a serving IWF and a home 
IWF. These parameters include the home-foreign shared secret, the home IWF-serving IWF tunnel configuration, etc. 
The FDD is preferably tocated in the home registration server's MSC. The FDD is used by home registration servers 
for registering roaming end systems. 

[0151] The following information will be stored in the FDD. 

1 . Foreign Domain Name. This field is used as the key to search the FDD for an entry thai matches the fully qualified 
domain name of the foreign registration server relaying the registration request. 

2. Shared Secret This is the shared secret used between the foreign and home registration servers to authenticate 
their identity mutually with each other 

3. Home IWF-Sen/ing IWF Tunneling Protocol Parameters. This field is used to store parameters to configure the 
tunnel between the home IWF and the serving IWF At a minimum, this field contains the type of tunneling protocol 
to use and any tunneling protocol specific parameters. For example, this field may contain the identifier for the 
tunneling protocol L2TP and any additional parameters required to configure the L2TP tunnel between the serving 
IWF and the home IWF 

4. Accounting Server Association. This field is used to sitore information needed by the home IWF to generate 
accounting data on behalf of the end system. It contains the name of the accounting protocol (e.g. RADjUS), the 
DNS name of the accounting server and additional parameters specific to the accounting protocol like the UDP 
port number, the shared secret that the IWF must use in the Radius Accounting protocol, the frequency of check- 
pointing, the seed for creating the session/multi-session id, etc. The accounting server's DNS name is translated 
to the accounting server's IP address, which is sent to the foreign agent. 

[0152] For wireless service providers that have roaming agreements with each other, the FDD is used to do authen- 
tication and complete the registration process. If an end system roams from its home network to a foreign network, the 
registration server in the home network consults the FDD in its MSC to get information and authenticate the foreign 
network providing service to the end system. 

[0153] The foreign domain directory management software provides a graphical user interface (GUI) based FDD 
management interface tor system administrators. Using this GUI, system administrators are able to view and update 
entries in the FDD. This GUI is not intended for use by foreign wireless network service providers to perform remote 
updates based on roaming agreements. It is only intended for use by trusted personnel of the home wireless service 
provider operating behind firewalls. 

[01 54] The internet service provider directory (ISPD) is used by Ihe home IWF lo manage conneclivily with ISPs lhal 
have service agreements with the wireless service provider so that subscribers may access theii ISPs using the net- 
work. For each subscriber, the subscriber directory has an entry for the subscriber's ISP. This field points to an entry 
in the ISPD. The home IWF uses this information to set up the connection to the ISP on behalf of the subscriber 
[01 55] The network architecture supports roaming. In order for roaming to work between wireless service providers, 
the architecture must support the sotting up of roaming agreements between wireless service providers. This implies 
two things: (1 ) updating system directories across wireless service providers and (2) settlement of bills between service 
providers. 

[0156] In order to allow subscribers access to internet service providers, the architecture supports roaming agree- 
ments with internet service providers. This implies that the architecture must be able to send data to and receive data 
from ISP PPP servers (i e , that support industry standard protocols like PPR L2TP and Radius), It also implies that 
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the architecture handles directory updates for ISP access and settlement of bills with ISPs. ^ 
[01 57] When roaming agreements are established between two wireless service providers, both providers have to 
update their home and foreign domain directories in order to support authentication and registration functions for end 
systems visiting their networks from the other network. At a minimum, the architecture of the present embodiment 
supports manual directory updates. When a roaming agreement is established between two wireless service providers, 
then the two parties to the agreement exchange information for populating their home and foreign domain directories. 
The actual updates of the directories is done manually by the personnel of the respective service providers. If later 
the information in the home and foreign domain directories needs to be updated, the two parties to the agreement 
exchange the updated information and then manually apply their updates to the directories. ^ ^ ■ ,k 

roi 58] In an alternative embodiment, the directory management software incorporates developing standards in the 
IETF to enable roaming between inter net service providers and to enable ISPs to automatically manage and discover 
roaming relationships. This makes manual directory management no longer necessary. The network system automat- 
ically propagates roaming relationships, and discovers them, to authenticate and register visiting end systems, 
roi 591 At a minimum, the network architecture just processes and stores the accounting data and makes he data 
available to the wireless service provider's billing system. It is up to the billing system to handle settlement of bills for 

[oi60r In an alternative embodiment, developing standards in the IETF to handle distribution of accounting records 
between internet service providers are incorporated into the network architecture to enable ISPs to do billing settlement 

for roaming end systems. ^^^^^ 
[01 61] The system software supports access to ISPs and private inlranels by supporting L2TP between the fiome 
IWF and the ISPs or intranet PPP server. The internet service provider directory contains information useful to the IWF 
for creating these tunnels. As access agreements between the wireless service provider and internet seivice providers 
are put in place, this directory is updated manually by the wireless seivice provider's personnel. Automatic updates 
and discovery of access relationships between the wireless service provider and internet service providers are presently 
contemplated and implemented as the internet standards evolve. While accessing an internet son/ice provider, the 
subscriber receives two bills - one from the wireless service provider for the use of the wireless network and the second 
from the internet sen/ice provider. Although common billing that combines both types of charges is not handled by the 
minimum embodiment software, rt is contemplated that the software will take advantage of inter net standards for billing 
settlement as they evolve so that subscribers may receive a common bill based on roaming agreements between the 
ISP and wireless service providers ,- ,u i f 

[01 62] The system includes a element management system for managing the network elements. From the element 
manager system administrators perform configuration, performance and fault/alarm management functions. The ele- 
ment management applications run on top of a web browser. Using a web browser, system administrators rinanago the 
network from anywhere that they have TCP/IP access The element manager also perfomns an agent role for a higher 
level manager. In this role it exports an SNI^IP MIB for alami and fault monitoring. 

[0163] A higher level SNMP manager is notified of alarm conditions via SNMP traps. The higher level SNMP manage 
periodically polls the element manager's MIB for the health and status of the network. System management personnel 
at the higher level manager are able to view an icon representation of the network and its current alarm state. By 
pointing and clicking on the network element icon, systems management personnel execute element management 
applications using a web browser and perform more detailed management functions. 

[0164] Inside the network, management of the physical and logical network elements is performed using a combi- 
nation of the SNMP protocol and internal management application programming interfaces. Applications in the element 
manager use SNMP or other management APIs to perform network management functions. 

[01651 Architecturally the element management system includes two distinct sets of functional elements. The first 
set of functional elements, including the configuration data server, performance data monitor and health/status monitor 
and network element recovery software, executes on an HA sen/er equipped with RAID disks. The second set of 
functional elements, including the management applications, executes on a dedicated, non-HA managennent system. 
Even if the element manager system becomes non-operational, the network elements continue lo be able lo run and 
report alarms and even be able to recover from fault conditions. However, since all the management applications 
execute in the non-HA element manager if the element manager goes down, then recovery actions requinng human 
intervention are not possible until the element manager becomes operational. „.,odx w 

[01661 The wireless hubs (WHs) in the base stations are typically owned by a wireless sen/ice provider (WSP). and 
thoy arc connected to the WSP's registration server (RS) either via point-to-point links, intranets or the Internet. The 
WSP's registration server is typically a software module executing on a processor to perform certain registration func- 
tions Inter-working function units (IWF units) are typically software modules executing on a pro«=essor to perform 
certain interfacing functions. IWF units are typically connected to the registration servers via intranets/WAN, and the 
IWF units are typically owned by the WSR However, the IWF units need not be located within the same LAhJ as the 
registration sen/ers Typically accounting and directory servers (also software modules executing on a processor) are 
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connected to the registration servers via a LAN in the service provider's Data Center (e.g. a center including one or 
nnore processors that hosts various servers and other software modules). Traffic from the end system is then routed 
via a router (connected to the LAN) to the public Internet or to an ISP=s intranet. The registration server located in a 
foreign WSP's network is referred to as the foreign registration server (FRS), and the registration server located in the 

5 end system's home network (where the mobile purchases its service) is referred to as the home registration server 
(HRS). the inter-working function unit in the home network is referred to as the home IWF while the inter-working 
lUMCiion unit in liie loreign network (i.e , the neiwork ihe end sysiem is visiting) is reierred io as the serving tVVF. 
[0167] For fixed wireless service (i.e., a non-moving end system), an end system may register for service on the 
home network from the home network (e.g., at home service) or from a foreign network (e.g., roaming service). The 

10 end system receives an advertisement sent by an agent (e.g. , an agent function implemented in software) in the wireless 
hub via the access point. There are both MAC-layer registration as well as network-layer registration to be accom- 
plished. These may be combined together for efficiency. 

[0168] For end systems at home (FIG. 23), the network layer registration (like a local registration) make*s known to 
the home registration server the wireless hub to which the end system is currently attached. An IWF in the end system's 
'5 home network will become the anchor or home IWF. Thus, PPP frames to and from the end system travel via the 
wireless hub to the home IWF in the home network. If the end system is at home, the home IWF is connected to the 
wireless hub via an XTunnel protocol. 

[0169] For roaming wireless service (FIG. 24), the foreign registration server determines the identity of the home 
network of the roaming end system during the registration phase. Using this infornnation, the foreign registration server 

20 communicates with the home registration server to authenticate and register the end system. The foreign registration 
server then assigns a serving IWF, and an l-XTunnel protocol connection is established between the home iWF and 
the serving IWF for the roaming end system. The serving IWF relays frames between the wireless hub and the home 
IWF. From the home IWF, data is sent to a PPP server (i.e., point-to-point protocol server) which may reside in the 
same IWF. However, if the data is to go to a corporate intranet or an ISP's intranet that has its own PPP server, the 

2S data is sent to the separate PPP server via the L2TP protocol. The separate server is typically owned and operated 
by an Internet service provider who is different from the wireless service provider For the duration of the session, the 
locations of the home IWF and PPP server remain fixed. The MAC layer registration can be combined with the network 
registration to economize on the overhead of separate communications for MAC layer and network layer registration; 
however, it may be advantageous to not combine these registration processes so that the WSP's equipment will be 

30 interoperable with other wireless networks that supports pure IETF Mobile-IP 

[0170] Registration sets up three tables. Table 1 is associated with each access point, and Table 1 identifies each 
connection (e.g., each end system) by a connection id (CID) and associates the connection id with a particular wireless 
(WM) modem address (i.e., the address of the end system or end system). Table 2 is associated with each wireless 
hub (WH), and Table 2 associates each connection id with a corresponding wireless modem address, access point 

35 and XTunnel id (KID). Table 3 is associated with each inter-working function (IWF), and Table 3 associates each con- 
nection id with a corresponding wireless modem address, wireless hub address, XTunnel id and IP port (IP/port). The 
entries described for these tables are described to include only relevant entries that support the discussion of mobility 
management. In reality, there are other important fields that need to be included as well. 
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[01 71] The protocol stacks for dial-up users at home in a network as well as roaming users are illustrated in FIGS. 
25-28 FIG 25 depicts protocol stacl^s used for direct internet access by a fixed (I.e.. non-moving) end system at home 
where a PPP protocol message terminates in the home IWF (typically collocated with the wireless hub) which relays 
message to and from an IP router and from there to the public internet. FIG. 26 depicts protocol stacks used for remote 
intranet access (i.e., cither private corporate nets or an ISP) by a fixed (i.e., non-moving) end system at homo whoro 
a PPP protocol message is relayed through the home IWF (typically collocated with the wireless hub) to a PPP server 
of the private corporate intranet or ISP FIG. 27 depicts protocol stacks used for direct internet access by a roamirig 
but fixed (i e , non-moving) or a moving end system where the PPP protocol terminates in the home IWF (tyP'oally 
located in a mobile switching center of the home network) which relays message to and from an IP router In FIG. 27, 
note how message traffic passes through a sending IWF (typically coltocated with the wireless hub) in addition to the 
home IWF FIG 28 depicts protocol stacks used for remote intranet access (i.e.. either private corporate nets or an 
ISP) by a roaming but fixed (i.e , non-moving) or a moving end system where a PPP protocol message is relayed 
through the home IWF (typically located in a mobile switching center of the home network) to a PPP server of the 
private corporate intranet or ISP. In FIG. 28, note how message traffic passes through a sen/ing IWF (typically collocated 
with the wireless hub) in addition to the home IWF When the serving IWF and the wireless hub are co-located in the 
same nest of computers or are even programmed into the same computer, it is not necessary to establish a tunnel 
usinq the XTunnel protocol between the serving IWF and the wireless hub. ^ .u 

r0172l Equivalent variations to these protocol stacks (e.g. the RLP can be terminated at the wireless hub rather than 
at the serving IWF or home IWF for mobiles at home) are also envisioned. If the IWF is located far from the wireless 
hub and the packets can potentially be carried over a lossy IP network between the IWF and wireless hub, then it 
would be preferred to terminate the RLP protocol at the wireless hub. Another variation is the Xtunnel between wireless 
hub and IWF need not be built on top of the UDP/IP Xtunnels can be built using the Frame Relay/ATM link layer. 
However the use of UDP/IP makes it easier to move the wireless hub and IWF software from one network to another 
[01731 Furthermore the PPP protocol can be terminated in a wireless modem and sent to one or more endsystems 
Via an ethernet connection. As illustrated in FIG. 29. the wireless modem 300 receives the PPP protocol information 
and encapsulates the PPP payload in an ethernet frame to be transported to at least one of the end systems 304 and 
306 via the internet connection 302. . • ^ .i, 

[01741 " DIX ethemet can be used lor encapsulating the XWD MAC primitives but the system is not limited thereto 
The ethemet frame format for XWD control frames is illustrated in Figure 30. The ethernet header contains a destination 
address a source address and an ethernet type field. The destination address field contains the ethernet address of 
the MAC entity to which the primative is being sent. For MAC primitives invoked by the MAC user, this field will contain 
the ethernet address of the MAC user. For broadcast primitives, this address will be the ethemet broadcast address. 
The source address field contains the othcmct address of the MAC entity invoking the primitive. The ethemet typo 
field contains the ethernet type for XWD. Possible values are XWD_Control for control frames and XWD.Data for data 
frames. These values must be different from all the ethemet type values that have been stnadardized and must be 
registered with the controlling authority 

r017Sl The ethernet frame then has an XWD header field. The XWD header can be 16 bits long and will only be 
present for XWD control frames. The fields are illustrated in FIG. 31 The ethemet frame also contains a protocol 
header, a PPP payload field and a XWD MAC field. The header values for primitives using ethemet encapsulation are 
illustrated in Table 4 below. 
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(continued) 
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[0176] In another alternative, the PPP protocol can be terminated in a wireless router and then sent on to at least 
one end system connected to a local area network (LAN). As illustrated in FIG. 32. the wireless router 350 receives 

30 the PPP protocol information via the wireless modem 352. The router 354 receives the PPP information from the 
wireless modem 352 and sends the PPP information to at least one of the end systems 356, 358, 360 via a LAN link 362. 
[0177] Four types of handoff scenarios may occur, and they are labeled: (1) local mobility, (ii) micro mobility, (iii) macro 
mobility, and (iv) global mobility. In all four scenarios (in one embodiment of the invention), a route optimization option 
is not considered so that the locations of the home registration server and the ISP's PPP server do not change. In 

35 another embodiment of the system with route optimization, the ISP=s PPP server may change. However, this aspect 
is discussed below. In addition, the locations of the foreign registration server and I WF do not change in the first three 
scenarios. 

[0178] The proposed IETF Mobile IP standard requires that whenever an end system changes the IP subnet to which- 
it is attached, it sends a registration request message to a home agent in its home sub net. This message carries a 

•^0 care-of address where the end system can be reached in the new subnet. When traffic is sent, for example, from an 
ISP to an end system, the home agent intercepts the traffic that is bound for the end system as it arrives in the home 
subnet, and then forwards the traffic to the care-of address. The care-of address identifies a particular foreign agent 
in the foreign subnet. An end system's foreign agent can reside in the end system itself, or in a separate node that in 
turn forwards traffic to the end system (i.e.. proxy registration agent). Mobile IP handoffs involve exchange of control 

•^5 messages between an end system's agent, the end system's home agent and potentially its corresponding hosts (CHs) 
(with route optimization option). 

[0179] The proposed IETF Mobile IP standard would find il difficult to meel Ihe latency and scalability goals for all 
movements in a large internetwork. However, the present hierarchical mobility management meets such goats. For 
small movements (e.g. a change of Access Points), only MAC-layer re-registrations are needed. For larger movements,. 

so network-layer re-registrations are performed. The present hierarchical mobility management is different from the flat- 
structure used in the IETF proposed Mobile-IP standard as well as the serving/anchor inter-working function mode! 
used in cellular systems like CDPD (based on a standard sponsored by the Cellular Digital Packet Data forum). 
[01 80] As depicted in Fl G. 33, the local mobility handoff handles end system (designated MN for mobile node) move- 
ment between APs that belong to the same wireless hub. Thus, only MAC layer re-registration is required. The end 

55 system receives a wireless hub advertisement from a new AP and responds with a registration request addressed to 
the new AP. 

[0181] The new AP (i.e , the one that receives the registration request from the end system) creates new entries in 
its connection table and relays the registration message to its wireless hub. In local mobility handoffs. the wireless hub 
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does not change. The wireless hub recognizes the end system's registration request as a MAC level registration re- 
quest, and it updates its connection table to reflect the connection to the new AP Then, the old AP deletes the connection 
entry from its connection table. There are at least three ways whereby the old AP can delete the old entries, namely 
(i) upon time out, (li) upon receiving a copy of the relayed MAC layer association message from the new AP to the 
wireless hub (if this relay message is a broadcast message), and (iii) upon being informed by the wireless hub of the 
need to delete the entry. 

[0182] As depicted in FIG. 34, the micro mobility handoff handles end system (designated MN for mobile node) 
movement between wireless hubs that belong to the same registration server and where the end system can still be 
served by the existing serving IWF. When an advertisement Is received from a new wireless hub (through a new AP), 
the end system sends a message to request registration to the registration server The registration request is relayed 
from the new AP to the new wireless hub to the registration server. 

[0183] When the registration sen/er determines that the existing IWF can still be used, the registration server sends 
a build XTunnel Request message to request the existing IWF to build an XTunnet to the new wireless hub. Later, the 
registration server sends a tear down XTunnel request message to request the existing IWF to tear down the existing 
XTunnel with the old wireless hub. The build and tear XTunnel Request messages can be combined into one message. 
A foreign registration server does not forward the registration message to the home registration server since there is 
no change of IWF, either the sen/ing IWF or home IWF 

[0184] Upon receiving a positive build XTunnel reply and a positive tear XTunnel reply from IWF, the registration 
server sends a registration reply to end system. As the registration reply reaches the new wireless hub. the connection 
table al the new wireless hub is updated to reflect the connection to the new AR The new AP updates its MAC filter 
address table and connection table after receiving a message from the new wireless hub, and the registration reply is 
forwarded to the end system. 

[0185] The registration server sends a release message to the old wireless hub. When the old wireless hub receives 
the release message, it updates its connection table and the MAC filter address table and connection table of the old AR 
[0186] As depicted in FIG. 35, the macro mobility handoff case handles movement between wireless hubs that in- 
volves a change of the serving IWF in the foreign network, but it does not involve a change in the registration sen/er 
When an advertisement is received from a new wireless hub (through a new AP), the end system sends a message 
to request a network layer registration to the registration server. The registration request is relayed from the new AP 
to the new wireless hub to the registration server 

[0187] The registration server recognizes that it is a foreign registration server when the end system does not belong 
to the present registration sen/er's network. This foreign registration server determines the identity of the home regis- 
tration server by using a request, preferably a Radius Access request (RA request), to the foreign directory sen/er (like 
a big yellow pages) and then assigns an appropriate IWF to be the serving IWF, and it forwards a registration request 
to the home registration server, preferably through a Radius Access request (RA request), informing the home regis- 
tration server of the newly selected IWF. 

[0188] The home registration server authenticates the registration request by using a request, preferably a Radius 
Access request (RA request), to the home directory server Upon authenticating the request and determining that the 
existing home IWF can still be used, the home registration server instructs the home IWF to build a new l-XTunnel to 
the newly assigned serving IWF and to tear down the existing l-XTunnel to the old serving IWF Upon receiving a 
positive build l-XTunnel reply and a positive tear l-XTunnel reply from the home IWF, the home registration server 
sends a registration reply to the foreign registration server 

[0189] The foreign registration sen/er then instructs the newly assigned IWF to build an XTunnel to the new wireless 
hub. Upon receiving a positive build XTunnel reply the foreign registration sen/er instructs the old IWF to tear down 
the XTunnel to the old wireless hub. Upon receiving a positive build XTunnel reply and a positive tear XTunnel reply, 
the foreign registration sen/er sends a registration reply to end system. 

[01 90] As the registration reply reaches the new wireless hub, the connection table at the new wireless hub is updated 
to reflect the connection to the new AR The new AP updates its MAC filter address table and connection table after 
receiving a message from the new wireless hub. and the registration reply is forwarded to the end system. 
[0191] The registration server sends a release message to the old wireless hub. When the old wireless hub receives 
the release message, it updates its connection table and the MAC filter address table, and the old AP updates its MAC 
filter address table and connection table after receiving a message from the old wireless hub. 

[0192] The global mobility handoff case handles movement between wireless hubs that involves a change of regis- 
tration servers. FIG. 36 depicts a global mobility handoff whore the homo IWF docs not change, and FIG. 37 depicts 
a global mobility handoff where the home IWF changes. When an advertisement is received from a new wireless hub 
(through a new AP) in a new foreign network, the end system sends a message to request a network layer registration 
to the new foreign registration server The registration request is relayed from the new AP to the new wireless hub to 
the new foreign registration server 

[0193] The registration server recognizes that it is a new foreign registration server when the end system does not 
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belong to the present registration server's network. This foreign registration server determines the identity of the home 
registration server by using a request, preferably a Radius Access request (RA request), to the foreign directory server 
(like a big yellow pages) and then assigns an appropriate IWF to be the serving IWF. and it fonwards the registration 
request to the home registration server preferably through a Radius Access request (RA request), informing the home 
registration server of the newly selected IWF. 

[0194] The home registration server authenticates the registration request by using a request, preferably a Radius 
Access rcqucSt (RA rt;qutfSt), io the i ioiiit; uii eclor y sei vei. upon aulhef liicaiiny Lhe request and deiermintng ihai ihe 
existing home IWF can still be used (FIG. 36). the home registration server instructs the home IWF to build a new I- 
XTunne! to the serving IWF newly assigned by the new foreign registration server. The home registration server also 
sends a de-registration message to the old foreign registration server and instructs the home IWF to tear down the 
existing l-XTunnel to the existing serving IWF of the old foreign network. Upon receiving a positive build l-XTunnel 
reply and a positive tear l-XTunnel reply from the home IWF, the home registration server sends a registration reply to 
the new foreign registration server 

[0195] The new foreign registration server then instructs the newly assigned IWF to build an XTunnel to the new 
wireless hub. Upon receiving a positive build XTunnel reply, the foreign registration server sends a registration reply 
to end system. As the registration reply reaches the new wireless hub, the connection table at the new wireless hub 
is updated to reflect the connection to the new AP. The new AP updates its MAC filter address table and connection 
table after receiving a message from the new wireless hub, and the registration reply is forwarded to the end system. 
[0196] The old foreign registration server instructs the old iWF to tear down the XTunnel to the old wireless hub. 
Upon receiving a positive tear XTunnel reply or contemporaneously with the tear down XTunnel request, the old foreign 
registration server sends a release message to the old wireless hub. When the old wireless hub receives the release 
message, it updates its connection table and the fvlAC filter address table, and the old AP updates its MAC filter address 
table and connection table after receiving a message from the old wireless hub. 

[0197] Alternatively, after the home registration server authenticates the registration request from the new foreign 
registration server and doterminos that the existing home IWF cannot bo used (FIG. 37). the homo registration server 
chooses a new home IWF and instructs the new home IWF to build a new level 2 tunnel protocol tunnel (L2TP tunnel) 
to the present PPP server (e.g., the PPP server in a connected ISP intranet). Then, the home registration server 
instructs the old home IWF to transfer its L2TP tunnel traffic to the new home IWF. 

[0198] Then the home registration server instructs the new home IWF to build a new l-XTunnel to the serving IWF 
newly assigned by the new foreign registration server The home registration server also sends a de-registration mes- 
sage to the old foreign registration server and instructs the home IWF to tear down the existing l-XTunnel to the existing 
serving IWF of the old foreign network Upon receiving a positive build l-XTunnel reply and a positive tear l-XTunnel 
reply from the home I WR the home registration server sends a registration reply to the new foreign registration server 
[0199] The new foreign registration sen/er then instructs the newly assigned IWF to build an XTunnel to the new 
wireless hub. Upon receiving a positive build XTunnel reply, the foreign registration server sends a registration reply 
to end system. As the registration reply reaches the new wireless hub, the connection table at the new wireless hub 
is updated to reflect the connection to the new AR The new AP updates its MAC filter address table and connection 
table after receiving a message from the new wireless hub, and the registration reply is forwarded to the end system. 
[0200] The old foreign registration server instructs the old IWF to tear down the XTunnel to the old wireless hub. 
Upon receiving a positive tear XTunnel reply or contemporaneously with the tear down XTunnel request, the old foreign 
registration server sends a release message to the old wireless hub. When the old wireless hub receives the release 
message, it updates its connection table and the MAC filter address table, and the old AP updates its MAC filter address 
table and connection table after receiving a message from the old wireless hub. 

[0201] End systems constructed according to the present system interoperate with networks constructed according 
to the proposed IETF Mobite-IP standards, and end systems constructed according to the proposed IETF Mobile-IP 
standards interoperate with networks constructed according to the present invention. 

[0202] Differences between the present system and the IETF Mobile-IP (RFC2002, a standards document) include: 

(i) The present systemists a hierarchical concept for mobility management rather than a flat structure as in the 
proposed IETF Mobile-IP standard. Small mobility within a small area does not result in a network level registration. 
Micro mobility involves setting up of a new Xtunnel and tearing down of an existing Xtunnel. Global mobility at the 
minimum, involves setting up of a new l-XTunnel and tearing down of an existing l-Xtunnel apart from the setting 
up/tcaring down of XTunnel. Global mobility sometimes also involves sotting up a now L2TP Tunnel and transferring 
of L2TP state from the existing L2TP Tunnel to the new L2TP Tunnel. 

(ii) In the present invention, a user name plus a realm is used to identify a remote dial-up user rather than a fixed 
home address as in the case of the proposed IETF Mobile-IP standard. 
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duplicate packet. The second approach is probably preferable to the first approach for the old wireless hub may not 
be able to communicate with one another directly 

[0211] For macro mobility, the old serving IWF can forward packets to the new sending IWR in addition to the packet 
forwarding done from the old wireless hub to the new wireless. All we need to do is to forward the new serving IWF 
identity to the new serving IWF in the tear down l-XTunne! message. Another way to achieve the same result is to let 
the home IWF forward the missing packets to the new serving IWF rather than asking the old serving !WF to do the 
jOu Since Ine ItOiVie iWF knows Irie i-XTuruiei sequence number last acknowiedged by the old serving IWF and the 
current l-XTunnel sequence number sent by the home IWF. 

[0212] The method of estimating how much buffer should be allocated per mobile per AP per wireless hub per IWF 
such that the traffic loss between handoffs can be minimized is to let the end system for the AP for the wireless hub 
for the IWF estimate the packet arrival rate and the handoff time. This information is passed to the old AP of the wireless 
hub of the IWF to determine how much traffic should be transferred to the new AP of the wireless hub of the IWF, 
respectively, upon handoffs. 

[0213] To achieve route optimization in the present invention, the end system chooses the PPP server closest to the 
serving IWF. Without route optimization, excessive transport delays and physical line usage may be experienced. 
[0214] For example, an end system subscribed to a home network in New York City may roam to Hong Kong. To 
establish a link to a Hong Kong ISR the end system would have a serving IWF established in a wireless hub in Hong 
Kong and a home IWF established in the home network in New York City. A message would then be routed from the 
end system (roamed to Hong Kong) through the serving IWF (in Hong Kong) and through the home IWF (in New York 
City) and back to the Hong Kong ISR 

[0215] A preferred approach is to connect from the serving IWF (in Hong Kong) directly to the Hong Kong ISP. The 
serving IWF acts like the home IWF. In this embodiment, roaming agreements exist between the home and foreign 
wireless providers. In addition, the various accounting/billing systems communicate with one another automatically 
such that billing information is shared. Accounting and billing information exchange may be implemented using stand- 
ards such as the standard proposed by the ROAMOPS working group of the IETF 

[0216] However, the serving IWF must still discover the closest PPP server (e.g., the Hong Kong ISP). In the present 
embodiment, the foreign registration server learns of the end system's desire to connect to a PPP server (e.g., a Hong 
Kong ISP) when it receives a registration request from the end system When the foreign registration server determines 
that the serving IWF is closer to the desired PPP server (e.g.. the Hong Kong ISP) than the home IWF is. the foreign 
registration server instructs the serving IWF to establish an L2TP tunnel to its nearest PPP server (in contrast to the 
PPP server closest to the home registration server and home IWF). Then, the foreign registration server informs the 
home registration server that the end system is being served by the sen/ing IWF and the foreign RPR 
[0217] In an alternative embodiment, the foreign registration server determines that the serving IWF is closer to the 
desired RPR server (e.g., the Hong Kong ISP) than the home IWF is, when it receives a registration request from the 
end system. The foreign registration server relays the registration request message to the home registration server 
with an attached message indicating the serving IWF information and a notification that route optimization is preferred. 
At the same time, the foreign registration server instructs the serving IWF to establish an L2TP tunnel to the PPP 
server. Upon approving the registration request, the home registration server instructs the home IWF to transfer the 
L2TP state to the foreign IWF 

[0218] Having described preferred embodiments of a novel network architecture with wireless end users able to 
roam (which are intended to be illustrative and not limiting), it is noted that modifications and variations can be made 
by persons skilled in the art in light of the above teachings. For example, connection links described herein may make 
reference to known connection protocols (e.g., IP. TCP/IP, L2TR IEEE 802.3, etc.); however, the system contemplates 
other connection protocols in the connections links that provide the same or similar data delivery capabilities. Acting 
agents in the above described embodiments may be in the form of software controlled processors or may be other 
form of controls (e.g., programmable logic arrays, etc.). Acting agents may be grouped as described above or grouped 
otherwise in keeping with the connection teachings described herein and subject to security and authentication teach- 
ings as described herein. Furlhermore, a single access poinl. access hub (i.e., wireless hub) or inter-working function 
unit (IWF unit) may provide multi-channel capability. Thus, a single access point or access hub or IWF unit may act on 
traffic from multiple end systems, and what is described herein as separate access points, access hubs or IWF units 
contemplates equivalence with a single multichannel access point, access hub or IWF unit. 



Claims 

1. A wireless data network comprising: 

a home network that includes a home mobile switching center a wireless modem and at least one end system. 
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